When it comes to SharePoint, there is just one way of packaging up your code; SharePoint solutions (WSP files). For 2010 the developer support in Visual Studio makes this a reasonably effortless exercise. For 2007 you have to use third party tool such as WSP Builder or roll out your own system; this lead people to use all sorts of fun combinations of MSI, XCOPY and CMD files.

For 2010 there is absolutely no excuse for not using WSP’s. If you are considering a third party vendor that is not using WSP’s, give them a pass and move on to the next candidate. This may sound overly harsh to some, but there are some very good reasons for this view.

Using WSP’s you get the following benefits:

  • A standardized way of deploying code to your system.
  • A container for all your customizations.
  • The customizations are applied to all the servers in your farm.
  • If you add new machines to the farm at a later time, the customizations are pushed out to those.
  • It’s easy to remove your customizations from all the servers in the farm.

For a developer it may not make much of a difference, but for the people maintaining the system it sure does.

Now that you know why it’s a good idea, how do you structure them? The following information is not targeted at those developing products, but rather those that are creating SharePoint systems containing customizations across several of the functional areas.

In Visual Studio 2010, one SharePoint Solution equals one Visual Studio Project; not Visual Studio Solution.

I prefer starting with the Empty SharePoint project and build on that.

My initial breakdown is as follows:

  • One WSP for common functionality
  • One WSP for each functional area in the system
    Search, Publishing, Collaboration, Record Center, My Site, etc.
  • One WSP for each system integration
    HR, Third party Document/Record Management system, CRM, ERP, etc.

Collaboration is a very generic term, so in some cases it might be appropriate to split this into several WSP files.

The idea behind this breakdown is the ability to deploy updates to parts of the system without affecting the others. Search and My Site may have very different change rates. Dependencies between the packages should be limited as much as possible. Ideally they should only depend on the common package. For the integration packages, it makes sense if they depend on relevant packages. I.e. dependencies between an HR package and My Site may be reasonable.


Development strategies

SharePoint is a very tantalizing piece of software; you can do so much from the web browser without having to touch anything as cryptic as Visual Studio. This ease of access doesn’t come without a price.

With a bit of training, your good old granny can create a site, add a whole bunch of lists, customize some views, and add a workflow or two all from the comfort of her web browser. For good measure, she uploads the complete works of Barbara Cartland and here knitting patterns. After some time it becomes apparent that she needs a background job to analyze the correlation of colors across knitting patters. You being her favorite grandson and a “SharePoint developer” are asked to help out poor old granny. When you stare at her in disbelief and start talking about cross environment testing, she just gives you a blank stare and says “Be a good boy and do as your grandmother tells”.

If you start your development using the web browser, you will at some point hit a brick wall. There is a band aid called SharePoint Designer that may help you out for a while, but at some point you will find yourself in territory where only Visual Studio is the solution. The moment Visual Studio is put on the table, testing becomes a concern as well. In order to test something, it has to be reproducible across multiple environments. Taking something created in one environment and moving it to another may not be a trivial matter. If we replaced Barbara Cartland’s complete works with diplomatic correspondence, you would get arrested for moving information around.

For any serious SharePoint development, there is only one answer: Visual Studio.

  • Version control all your files
  • Everything that is possible to do is actually possible; no more hitting brick walls.
  • Your customizations can easily be packaged up and deployed across as many environments as you desire.

Version control should not be underestimated. If you ever get into a dispute, a lot could be resolved by deploying the latest version to a clean environment and see what works there.