By default SharePoint 2010 allows you to have only one version of a particular WSP deployed in the Farm. While it’s not an issue in many scenarios, as soon as you start working with multiple sites using functionality from those WSPs things will get more challenging. So how should you deal with shared components?

Multiple sites? Big deal!

As we all know by now SharePoint 2010 is a platform where you can easily host multiple sites on the same Farm. No matter if your sites are divided into separate Web Applications or exist closer to each other as (Host Named) Site Collections, using single Farm for hosting multiple sites allows you to get more out of SharePoint and make better use of the available resources.

Although the reasoning behind using either Web Application or Site Collections or a combination of them will vary per scenario, the point is that no matter your choice, SharePoint 2010 offers you great flexibility in terms of hosting multiple sites on a single Farm.

The anatomy of a shared component

When extending the functionality of the SharePoint platform, you can provide your users with components that they can leverage in their business solutions. A component can be as small as a single TextBox and as large as a complete business solution spanning across multiple Solution Packages. A menu control, a twitter Web Part, a Media Player, a solution for generating XML Sitemap for your site – are all examples of components that you might build to extend the capabilities of the SharePoint platform. Depending on the functionality of your component, different packaging strategies apply and there are valid scenarios for every approach.

IReusable

Building a component for a single site is fun but offers you little benefit in the long run. If your component is too tightly coupled to the site for which it’s been primarily built, the odds are high that the next time a similar, but not exactly the same, component is requested by your customer, you will have to build it from scratch again. Not only is this a waste of your time but it also complicates the maintenance of all those lookalike components.

Building generic and reusable components is more complex and requires more effort upfront but in the end allows your customer to save money, support organization to save time, and you to focus on new functionality instead of reinventing the wheel.

Reusing components across multiple sites

If you use a component on a single site the situation is easy: you update the component as needed, test if it’s working as expected on the particular site and you update it in the production environment.

When you start working with multiple sites, reusing components that are already available is a great idea - not only from the productivity perspective but also from the standardization point of view. Because multiple sites use the same components, they work in a similar way and less specific knowledge is required to support them. Initially, when building a new site, being able to use existing components offers you great productivity and allows you to focus on the new functionality. And while you won’t notice any of it during the first release of your site, reusing components comes with a price that you will have to pay as soon as a change to that component is requested.

Modifying a component that is used on multiple sites is a complex process. Not only you must identify which sites use that component but also you have to retest all of those sites to ensure that the component is working correctly on all of them. The challenging part is, that the update of that component is very likely requested by one of the sites and other sites have basically no interest in the additional effort of getting retested. This can get you in a tricky situation especially if the different sites are the property of different departments each with its own budget. Ideally you would just want to have multiple versions of the same component deployed on the Farm and avoid unnecessary tests altogether…

Multiple versions of the same Solution Package

When developing functionality for the SharePoint platform, in order to ensure of its proper deployment across all servers in the Farm, it’s the best to wrap it in a Solution Package (WSP).

By default SharePoint allows you to have only one version of a specific WSP deployed in the Farm. This has mostly to do with the fact that a Solution Package can contain files that are deployed either to the Web Application or the SharePoint Root folder (14) which are regular Windows folders and which don’t support file versioning. This sounds like the end to the reusability story and the equation of reusability and high costs involved with testing, doesn’t it? After all, if we are not able to deploy multiple versions of the same Solution Package to a Farm, how are we supposed have multiple versions of the same component available?

Depending on the type and contents of your Solution Package there are different challenges with regard to having multiple versions of the same WSP deployed in the Farm. Before we analyze the contents of specific types of Solution Packages, let’s first take a look at what would be needed for us to have multiple versions of the same WSP deployed to a Farm. You should also keep in mind that, since SharePoint doesn’t support it natively, implementing support for multiple versions for a WSP often feels like hacks and workarounds which it basically is.

Prerequisites for hosting multiple versions of the same Solution Package

Although the SharePoint 2010 platform allows you to work with two types of Solution Packages – Farm and Sandboxed Solutions, they are similar from the versioning perspective.

WSP filename

First there is the name of the WSP file. In order to support multiple versions of the same package the name of that WSP file would have to be different for every version. Preferably you would include the version number in the file name, for example: Mavention.SharePoint_1.2.0.0.wsp.

Solution ID

Next there is the Solution Manifest file which is packaged in the WSP (Manifest.xml). The Solution Manifest contains the Solution ID which uniquely identifies that Solution in the Farm. For each release you would have to change that ID to ensure that the different versions won’t collide.

Assemblies

For assemblies deployed to GAC you would have to change the Assembly Version to ensure that all the different versions are deployed next to each other. Preferably you would align the assembly version with the Solution Package version just to make it easier for yourself to track to which version it belongs.

If you deploy assemblies to the Web Application, you are in a bad position when talking about the support for multiple versions. The bin directory of a Web Application doesn’t really support deploying multiple versions of the same assembly and with that there is no realistic workaround for you to use.

Features

With regard to Features there are two important things when considering the support for multiple versions. First there is the name of the Feature folder which should be unique for every release. Next there is the Feature ID which should as well be changed for every release to avoid conflicts.

Layouts files

Another commonly used location for deploying files is the Layouts folder in the SharePoint Root. Since it’s nothing more than a Windows folder, in order to support multiple versions of the same WSP, you would have to deploy your files to a unique subfolder in order to avoid overwriting files from other versions of the same component.

An educated choice

As you can see, implementing support for multiple versions for a WSP comes at a very high price. Not only you have to change the IDs and deployment paths every time you release a new version of your component, but you also step away from the ability to upgrade Solution Packages. Although we have touched just a few of all the different assets that a WSP can provision to a ShrePoint Farm, it’s clear that all of this effort makes it not worth it to implement support for multiple versions of a WSP.

One exception to this, that might be worth investing in, is if you had a reusable component library with controls and Web Parts which would consist of an assembly (one or more) deployed to GAC only. In such case giving in on the Solution Upgrade ability is not a big issue and changing the Assembly Version and the Solution ID on each release is something you automate within your build environment without too much effort. The great benefit here is, that you could have multiple versions of your components library deployed to your Farm and have the sites decide themselves which version do they want to use and when do they want to update.

Summary

SharePoint 2010 is a platform that allows you to host multiple sites on a single Farm. Unfortunately by default it doesn’t allow you to have multiple versions of the same component deployed which negatively impacts the test effort required for each new release of a shared component used across multiple sites. Although some workarounds are theoretically possible, they are only worth effort with regard to Solution Packages that contain only assemblies deployed to GAC.