Strong Naming Assemblies For Sharepoint Part 2: Updating Specific Version References

10 September 2012

Without access to the source code for assemblies, you can add sign / add strong names for them for use in SharePoint via ildasm and ilasm (for which the instructions I previously wrote about).

However, consider the scenario where:

Assembly A (unsigned) has a reference to a specific version of Assembly B (also unsigned).

I tried going the regular ilasm route, but Visual Studio kept complaining that it was expecting the unsigned version of Assembly A (version=1.0.0.0 publickeytoken=null). There were a few mentions of hooking up to the AssemblyLoad/Binding parts during run-time, but that still wouldn't solve our compile-time errors.

Enter this blog post about changing and rebuilding assemblies to update referenced assemblies - turns out all we need to do to get our situation working properly is to insert the public key token as part of the reference.

Before the ilasm step, open up the .il file, and at the top you can see the referenced assemblies and edit yours to include the PKT:

// Metadata version: v2.0.50727
.assembly extern mscorlib
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 2:0:0:0
}
.assembly extern My.Assembly
{
  .publickeytoken = (B4 5D C7 B6 5B C4 C7 0E )                         // .z\V.4..
  .ver 1:0:0:0
}
.assembly extern System.Core
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 3:5:0:0
}
.assembly extern System.Web
{
  .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A )                         // .?_....:
  .ver 2:0:0:0
}

My guess, as stated on StackOverflow, was that with specific version referencing, the publickeytoken requirement is implicit which is why we needed to define it - but if anyone knows more or has a cleaner way of porting both unsigned assemblies to signed versions, let me know! :)

Tags: assemblies, ildasm, publickeytoken, references, SharePoint

Add a Comment

No Comments