Recently been working on some SharePoint stuff which required using a few external libraries - and as you may well know, SharePoint requires you to have strong named assemblies (ie, signed) for them to be deployed to the GAC. So what happens if you're given a compiled .dll, but not the source?
Turns out that with a bit of command line / dev tool magic, you can decompile and recompile (with key) any given assembly, which will make SharePoint less likely to cry. The steps are outlined here, but you'll essentially want to do the following from a VS.NET command prompt:
- Generate a KeyFile: sn -k keyPair.snk
- Obtain the MSIL for the provided assembly: ildasm providedAssembly.dll /out:providedAssembly.il<
- Rename/move the original assembly: ren providedAssembly.dll providedAssembly.dll.orig
- Create a new assembly from the MSIL output and your assembly KeyFile: ilasm providedAssembly.il /dll /key= keyPair.snk
The only gotcha for SharePoint 2010 (not sure about the upcoming 2013) is that if you've got .NET 4.0 installed, the path defaults to using the .NET 4.0 ilasm, which will generate a .NET 4.0 assembly (which you can't use with SharePoint). To fix this, simply update the PATH variable in the command prompt to exclude C:\Windows\Microsoft.NET\Framework\v4.0.30319 and include C:\Windows\Microsoft.NET\Framework\v2.0.50727 instead.
If you're signing assemblies that have specific version references, take a look at part 2 which shows you how to update those to include the new publickeytokens.