This post is migrated from previous hosting provider. There are still some issues with old posts. Please make a comment on this post with any issues.

Web Part Versioning with assembly redirection

Tags: SharePoint, Web Parts

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>

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: , ,

No Comments

  • Wictor said

    Thanks Tom. There are no "best practices" out there as I have seen, so I wrote out the alternatives. Then it's up to us, developers, to choose which approach to use. Have a nice christmas.

  • Wictor said

    Redirection works fine for assemblies (such as web parts) as described above. Versioning of templates and content types is one thing that SharePoint does not have any good support of, nor have I any good solution/workaround. Esp when working with content types this is problematic, best practice is to only make upgrades programatically, ie dont touch the CTs master XML file. /WW

  • Ryan Wheeler said

    Hi Victor. There are best practices and they recommend keeping the AssemblyVersion the same and changing AssemblyFileVersion - see KB556041 or this page for more details http://stackoverflow.com/questions/1035284/sharepoint-features-how-can-i-use-wildcard-assembly-versioning

  • Wictor said

    For SharePoint you should avoid using AssemblyVersion as much as possible - unless you like to keep a lot of SafeControl entries in your web.config and cleaning them up properly. That KB article is for .NET development and the SO answer is just plain wrong IMO.

Comments have been disabled for this content.

About Wictor...

Wictor Wilén is the Nordic Digital Workplace Lead working at Avanade. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint  and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) for seven consecutive years.

And a word from our sponsors...