Elton Stoneman

[Source: http://geekswithblogs.net/EltonStoneman]

I was debugging a particularly nasty problem and found myself wanting to edit the manifest of a compiled .NET assembly, to change the version number of the assemblies it was referencing. Not necessarily best practice, but in this case it would enable me to confirm the exact issue without a two-hour build-and-deploy cycle. Turns out that nasty hacks like this are very straightforward:

1. Run ILDASM, open the assembly and choose File…Dump to extract the IL
2. Open the IL file in Visual Studio and edit the manifest – in this case, the version numbers of the referenced assemblies are easily found at the top of the file:

   // 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 x.y.z
   {
     .publickeytoken = (E4 21 0D 54 23 66 A2 B4 )                         // . .D'f..
     .ver 1:0:9:12
   }

3. Save the IL and reassemble it with ILASM – if the assembly was signed, re-sign it using ilasm /DLL x.y.z.il /KEY=x.y.z.snk
4. Ensure the new assembly has the same name as the original, and it will operate as an exact replacement, only now its dependencies will be for the modified versions.

Simon McEnlly's article on CodeProject describes going further with the manifest to change the visibility of methods, and generally modifying and rebuilding assemblies where you don't have the source code. Note that if the assembly is signed and you don't have the strong name key to re-sign it, the modified assembly will warn about being tampered with and won't load.