Guest Author: Benjamin Curry, SharePoint MVP

I remember Steve Ballmer screaming ‘developers, developers, developers’ back at TechEd (I think it was TechEd, don’t remember the year). That’s what I feel like when I meet with clients talking about Best Practices – SOLUTIONS, SOLUTIONS, SOLUTIONS!! Just say yes to solutions. Maybe I can get Todd Bleeker to do the SOLUTIONS rant and record it! That would be awesome :-)

So if solutions (WSP = SharePoint Solution Package) are so important, why don’t all developers use solutions? Because they either don’t know how, think it’s too difficult, or don’t want to take the time to package them. Before we look deeper into this bad practice of not using solutions, let’s look at WHY it’s a bad idea. First, let me describe a scenario I’ve been through multiple times with clients in the real world:

Real World Scenario from an Admin Perspective:

Server is toast, or worse – farm is toast. So, you followed the best practice of scripting your farm install, so you restore your databases and script the servers back to life, but you get NOTHING when you browse to the site. You check IIS,all of the Web applications and app pools - they look fine. SO, you monkey with the install, still – nothing. Argh… OH! I forgot we had a custom site definition. So, you copy the site definition from a backup (you now restore to a temporary server and go make coffee and play some Tomb Raider while the server restores) and the page renders. What? Now, I have lots of Web part errors. Oh, the Web parts were all manually installed. But, they don’t work correctly after you get them back installed. Argh… OH! They have dependent features that aren’t installed. Ok, you get the features back and no images? What? Are you kidding? Arghhhhh… Oh, I see, the custom site def has images that I know have to copy. So I feel like we’re almost there, except I have web.config changes to make, but at least the server is up. Ok, imagine this on a large scale and add lots of site defs and features.

One more thing, what if you needed to remove and/or upgrade items that were already deployed? How are you going to consistently remove it on all servers in a farm? It’s like hacking through the briars with a tire iron…

–end scenario–

While it might seem faster to simply deploy ‘stuff’ directly to the server, the long term supportability is really going to suffer. The problem we have encountered again and again is people have had initial success manually deploying artifacts, but over time as more items are deployed to larger number of web application and more servers, inconsistencies arise. These problems can be very difficult to diagnose because they are inconsistent, only occurring on the servers and web apps that have not been maintained correctly. The process of elimination to locate the offending items is often lengthy and the solution is the creation of WSPs which should have been created in the first place.

If WSPs offer so many advantages the obvious question that arises is don’t people always use them?  The answer is that creating a WSP will add extra steps to the development and deployment process and in the initial stages of SharePoint implementation it is seems simple to use other methods bypassing the learning curve that WSPs require. Consider the following situation which is based upon multiple real world incidents.

A single web part is developed using strict development best practices. That web part will require the following files and configuration changes:

1. A .dll to be deployed to the web application BIN directory so that it can implement Code Access Security.
2. A .webpart XML file that will specify the .dll, namespace, and class for the web part and defines properties for it.
3. A Feature.xml file that is one of two files used to copy the .webpart XML file to the Web Part gallery of the site collection.
4.  An Elements.xml file that is one of two files used to copy the .webpart XML file to the Web Part gallery of the site collection.
5. A Safe Control entry for the web application’s web.config file that grants permission for the web part to run.
6. Code Access Security policies that defines what the web part will be allowed to do.

When the number of servers and web applications is relatively small it seems easier to make these changes manually than use a WSP. Unfortunately as the number of servers and web applications increase the process become rapidly more complex. Consider the example of our simple web part example it requires 6 actions to deploy to a single web application on a single server.  But if we increase the number servers and web applications to 3 each the number of changes increases to 36.

1. A .dll to be deployed to the web application BIN directory so that it can implement Code Access Security. (Deploy to 3 web app bin directories on 3 servers = 9 changes)
2. A .webpart XML file that will specify the .dll, namespace, and class for the web part and defines properties for it. (Deploy to 12\TEMPLATE\FEATURES on 3 servers = 3 changes)
3. A Feature.xml file that is one of two files used to copy the .webpart XML file to the Web Part gallery of the site collection. (Deploy to 12\TEMPLATE\FEATURES on 3 servers = 3 changes)
4.  An Elements.xml file that is one of two files used to copy the .webpart XML file to the Web Part gallery of the site collection. (Deploy to 12\TEMPLATE\FEATURES on 3 servers = 3 changes)
5. A Safe Control entry for the web application’s web.config file that grants permission for the web part to run. (Change the web.config file for 3 web applications on 3 servers = 9 changes)
6. Code Access Security policies that defines what the web part will be allowed to do. (Change the web.config file for 3 web applications on 3 servers = 9 changes)

There are 3 more real world lessons learned that should be mentioned here. These problems are not limited simply to web parts and related files. Items as simple as images and as complex site definitions (the blueprints that detail the creation of SharePoint sites) are all effected by improper non-WSP deployment. Site definitions, field types, event receivers, workflow, features all must be deployed via WSP. In addition CSS files, ASPX pages, and Master Pages will need to be deployed via WSP if they are to be used farm wide. As a general rule, if the item in question will affect the entire farm it will likely need to be deployed via WSP.

WSP need to be used consistently. A commonly encountered problem is that of someone deploying a .dll via WSP and then manually replacing it as a bug fix. When a new server is added to the farm and the old WSP is deployed the servers are now out of sync. Similar problems could arise if it becomes necessary to rebuild a server.

Using WSPs and features can make deploying dependencies much easier. Consider the AJAX web.config feature that is available for free from CodePlex. The feature will automatically make the required web.config changes to allow AJAX Extensions to be used in SharePoint. The feature can be found here: http://features.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=2502#DownloadId=17819

WSPs can greatly simplify disaster recovery situations, creating test and development environments that mirror production, or multiple geographically disparate SharePoint implementations. This can be enhanced further by the creation of a master script that adds deploys all WSPs consistently for the entire farm.

Thanks to Jim Curry for helping with the softie part of this blog :-) While I’m not a developer, I’m lucky to be surrounded by some top talent. You rock, Jim!

I’m already working on Bad Practice #3 – Implementing SharePoint with poor requirements.

Come see me at the Best Practices Conference, August 24-26 in Washington D.C.

Guest Author: Benjamin Curry, SharePoint MVP

Ben Curry – (CISSP, MVP) – is a Microsoft MVP and a highly respected enterprise architect specializing in knowledge management and collaboration technologies. As a senior instructor for Mindsharp, Ben shares his knowledge in training courses that cover the next generation of Microsoft products. Ben is the author or co-author of three books for SharePoint products and technologies, including the newly-released Microsoft Office SharePoint Server 2007 Best Practices by Microsoft Press. Ben has over fifteen years of experience designing, managing, implementing and securing data center IT solutions.

Ben’s Blog