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.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: