Assembly redirection in WSP

Recently I have started upgrading our utilities to the new SharePoint 2010 version,

One of my main goals there was to get rid of the MSI installer we had to use on our products for SharePoint 2007, and go with a "cleaner" installation process of using the SharePoint WSP package alone.

One of the challenges was that as an ISV we have no control over our customer's server, setup or versions installed. Which means, any customer may have any mix of products and versions at the same time.

For example: say we have 2 products - ProductA and ProductB (both at version 1.0.0.00) that were build using our shared utilities DLL: utilities.dll version 1.0.0.01

A month later, we add a new feature in our utilities.dll that is used on ProductB, so now we have upgraded our utilities to version 1.0.0.02 and our ProductB to version 2.0.0.00 and we publish that to the Internet.

Now our customer upgrades his copy of ProductB only.
We had 2 options here:
1. keep both utilities version
2. upgrade and keep only version 1.0.0.02

The first option was no good, since for example our utilities declare a feature called FeatureA. if 2 different packages declare that same feature, and one of them is retracted later on - the feature will be uninstalled with it (There are some other issues like this one, but this is not the scope of this article).

So, sticking with the second option was pretty simple: just install the latest version of utilities with no other older versions of it anywhere.
The only issue was, How will it "tell" all other older products (ProductA) to start using utilities.dll version 1.0.0.02?!

I have looked everywhere for a solution that was just under my nose.

Apparently in VS2010 and SharePoint 2010 there is a new XML node in the package XML definition, right next to the assembly "SafeControls" node.

This new XML node is called "BindingRedirect", and it allows you to specify in the solution package itself any Assembly version redirection you might need!

Problem is - the package designer does not expose this property, so you have to enter it in the Package.Template.Xml directly.

here is how my package.template.xml file looks like:

The end result is:

And this simple produces the following entree in the web.config:

Now, as far as I tested:

1. Retracting solution cleans this entree up with no problem!
2. Deploying a new version upgrades this entree and does not create duplicate entrees!
3. It is safe (like in my example) to give a wide version range in the oldVersion property - even for future versions that do not exist yet. it will simply allow you not to update this every time you build a new version.

So far, this solution had worked out perfect for me, and it is by far the easiest and most simple way to do it in SharePoint than any other way I found on the web - so hope this helps any of you.

Cheers, Shai.

RSS