Monday, August 16, 2010

Branding, Design, Skinning, etc. for SharePoint 2010

Microsoft has sure done plenty to improve the look/feel and user experience in SharePoint 2010 over MOSS 2007, WSS, STS, etc. earlier editions of SharePoint. But alas there are always going to be people/groups who will want to spend money on more design customizations. To do so wisely I recommend the following procedures:

1. Think first. The proper term for site look/feel customizations in SharePoint is "branding". You also want your SharePoint 2010 "branding" to be usable long-term so stay tuned in to the key SharePoint 2010 branding strategies so you can have confidence that Microsoft will implement a migration path for future editions of SharePoint.
2. Make the focus of the design changes/implementations to be on the Master Pages. See http://startermasterpages.codeplex.com for a good starting point.
3. Read up on SharePoint 2010 branding. See http://www.sharepointpodshow.com/archive/2009/12/21/sharepoint-2010-branding-episode-40.aspx, http://www.sharepoint911.com/training/Pages/Branding2010.aspx, and http://community.bamboosolutions.com/blogs/sharepoint-2010/archive/2009/10/21/spc-customizing-amp-branding-my-sites-in-sharepoint-2010-with-heather-solomon.aspx to get started.
4. Understand the basics of what a WSP is. As you are building branding capabilities such as master pages, CSS, other stylings, etc. you will be doing so in SharePoint Designer, Visual Studio, Notepad, a CEWP or some other tools. Ultimately you'll want them all packaged up in WSP(s) for sustainability, maintainability, reusability, migrations, and collaboration. See http://www.bing.com/search?q=sharepoint+2010+WSP+%22Solution+Package%22 to get the latest info on WSP(s).

Wednesday, August 4, 2010

maxRequestLength and Large File Uploads for Web Server

I had an end user working with InfoPath Form Services in MOSS get an error when he attempted to load large attachments to his InfoPath document. Sure enough there was no httpRuntime tag in the machine.config file on the Web Front Ends (WFE), and thus no maxRequestLength attribute setting. The default value is 4096 which means 4096 kilobytes or 4 Meg. I upped it to 16 meg and the problem went away.

See http://msdn.microsoft.com/en-us/library/e1f13641(VS.71).aspx for technical specifications on the httpRuntime tag and its maxRequestLength attribute.

Here's a snippet of machine.config to demonstrate the concept.

<configuration>
<system.web>
<httpRuntime maxRequestLength=16384 />
</system.web>
</configuration>

You can locate the machine.config file in the MOSS WFE's .NET framework runtime's config directory within the Windows Microsoft.Net directory tree. In my case it was the C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Config directory.

Monday, August 2, 2010

Page_Load and OnLoad

Today I relearned an important lesson on the Page_Load and OnLoad event handlers for ASP.Net user controls. We cannot assume that they are one and the same in the page lifecycle. By default Visual Studio will create an event handler for Page_Load when you doubleclick on the designer panel for a user control.



This default behavior of Visual Studio set up a disaster in conjunction with my SharePoint development framework.

In my framework I've created a Framework.Base.BaseUserControl class that inherits from the System.Web.UI.UserControl class. The purpose of this BaseUserControl class is to serve as an ancestor class for all my user controls that get deployed with SharePoint solutions. In addition, the web part wrapper class (i.e. Framework.Base.BaseWebPart) assumes that the wrapped user control descends from this class.

Here's the OnLoad event handler in BaseUserControl.

protected override void OnLoad(EventArgs e)
{
this.MyBaseControlLoadLogic();
base.OnLoad(e);
}

Here's the result in Visual Studio for my user control.


protected override void Page_Load(EventArgs e)
{
base.OnLoad(e);
this.MyControlLoadLogic();
}


Everything compiles. But then all I got was a blank screen. I did some debugging and then discovered my mistake. The base.OnLoad(e) call im my Page_Load was causing a stack overflow that crashed my development web server. All I had to do was rename Page_Load as OnLoad.


protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
this.MyControlLoadLogic();
}

It worked :)