This post was migrated from an older system. Some links may point to content that no longer exists. Comments were not migrated.
Last week in the closing thoughts on the Binding Redirection post
, I mentioned there was a bug within the new 2010 functionality. Here's the scoop...
This bug won't affect every deployment. However, if you run across it, a couple of things will happen:
- Redirection will not work
- You're going to leave garbage in web.config - making admins unhappy with you
The bug is completely related to your public key token (PKT) and how SharePoint creates the value that is punched into the web.config.
Let's take a brief look at the problem, then I'll describe the problem in detail...
Let's assume that your public key token is
If you use the BindingRedirect element in your solution, the resulting output within web.config will be...
<assemblyIdentity name="VisualWebPartProject1" publicKeyToken="d614fd1952471d5" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-18.104.22.168" newVersion="22.214.171.124" />
Do you see the problem?
Split the PKT into 8 pairs - d6, 14, fd, 19, 52, 04, 71, d5
Notice that the 6th pair is 04 in the known, proper PKT.
However, the value in the publicKeyToken is written without the leading 0.
Yup, it's a simple little padding error. "04" is the same "4" if you are just looking at the single value; however, in order for the entire string to be correct, there needs to be 16 characters.
What is the effect?
The first and most apparent effect is that redirection simply does not work. The .NET framework will read the info and subsequently NOT find a match for your assembly.
The next problem is less visible. When you retract the solution, SharePoint will not clean up the bindingRedirect
it inserted during deployment. Net result
: you'll leave a lot of junk dependentAssembly tags in your web.config. admins will be unhappy (or more appropriately - more unhappy than normal!)
When you add a BindingRedirect to your solution, your solution manifest would like...
<Assembly Location="Bluedoglimited.Demo.dll" DeploymentTarget="GlobalAssemblyCache">
There are two things worth paying attention to here...
- The BindingRedirect element only requires the OldVersion attribute. Even though you know the PKT, you haven't specified it anywhere within the solution package.
- Hence, publicKeyToken and newVersion are calculated based on the actual assembly values once it has been loaded.
The calculation routine that generates the PKT produces the wrong value. If any pair is less than 0x0F (15), the resulting PKT string will be invalid.
There are two options worth considering:
If you want to use the new 2010 built-in functionality to deploy BindingRedirect instructions, your only recourse is to use a new public key that does not contain a paired value that is less than 0x0F.
If you can't change your key (because of company policy or legacy requirements), then SharePoint 2010's new functionality is not usable. You will need make accommodations to write your own bindingRedirect information - programmatically or, worse yet, manually. Either way, this is a probably not a good option for a number of reasons.
Finally, it's worth calling out this problem was reported shortly before RTM. I've received confirmation that problem has been located and may be addressed in a future update.