When working with SharePoint Web Parts and features it is easy to get into trouble if you are changing the version of your Web Part DLL file. The easiest way to get around this is to never change the version of the Web Part, which is a pretty common scenario. But if you are developing a product or feature that you expect to have a longer life cycle and that you will upgrade or enhance over time you should really use the assembly version features. Having a version on your Web Part will make it easier for you to support it for multiple customers and/or installations.

Web Parts are defined in the .webpart file with the full class name, including the version number, which makes it a bit troublesome to update. That is if you just change the DLL or reinstall your feature, with a new version, all of your added web parts will stop work, since it will no longer find the old assembly. To resolve this you have a couple of scenarios that I will briefly explain.

Parallel installation

.NET has allows you to have multiple parallel installations of the same DLL, with different assembly versions. This means that you can easily just install an updated Web Part into your farm and have all versions running in parallel. This requires you to create a new feature, if you use features to install your Web Parts.

This method is really easy to use and just requires you to create a new feature. The problem is supporting it, you can sometime have trouble finding out which version your clients are running.

Assembly Redirection

Using Assembly Redirection is, according to me, the best way to accomplish upgrades of your Web Parts. This means that you in your web.config specifies that all requests for a specific Web Part version is redirected to another. When using this all of your previous installed web parts will still work, as long as you did not change how certain web part properties works. If you make a complete new version, this method may not be suitable, then you should consider creating a new Web Part/feature and use the parallel mode.

Take a look a this code; it redirects all 1.0 to 1.5 versions to use the 2.0 version. This is specified in the web.config.

runtime>
  assemblyBinding>
    dependentAssembly>
      assemblyIdentity name="WebPart" publicKeyToken="ba74fbef247b82bb" culture="neutral" />
      bindingRedirect oldVersion="1.0.0.0-1.5.0.0" newVersion="2.0.0.0" />
    dependentAssembly>
  assemblyBinding>
runtime>

.csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, “Courier New”, courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

In a standard WSS 3.0 or MOSS 2007 installation you will see that there are already a lot of assembly redirects, from previous SharePoint versions to the current (from 11.0.0.0 to 12.0.0.0).

Read more about Assembly Redirection here.

Alternative/custom version numbering

There is also an method in which you completely ignore the built-in .NET assembly versioning and make your own versioning. This sample is described by Adam Buenz in SharePoint WebPart Versioning.

I think this method is not to prefer since then you need to access the actual UI of your component to see which version that is installed. You cannot find it out by looking to the .webpart file, the GAC, the SharePoint databases or the event logs.

What’s your take on Web Part versioning?

Technorati tags: Web Part, WebPart, SharePoint