Technology with opinion

Wednesday, August 26, 2009

Working Around DLL Hell in .Net

Assembly Bindings with different Public Key Tokens

There was a little fiasco started when log4net accidentally generated a new public key token for log4net from version to  This became evident to me when I tried to do an assembly redirect in the .config file for NAnt so that it would use the newer version of log4net.  You get the public key token from any .Net assembly by executing the following command on it:

If you perforrm this against log4net 1.2.9 & 1.2.10 you will get b32731d11ce58905 & 1b44e1d426115821.  Therefore if you are executing a custom task that requires log4net (or who's dependencies require log4net) .Net will not let you redirect the two version because as far as Microsoft is concerend, they are not two different version of the same thing, they are different assemblies altogether.  However since they are different assemblies technically the work around is to rename one of the new assembly (1.2.10 in this scenerio) filename to log4net-1.2.10.dll.  Next in the NAnt.exe.config add the following within the <configuration> element

This will force .Net to load the new assembly alongside the old one thus avoiding any compatibility issues, bypassing DLL hell for good.


adminjew said...

You might also want to try the Hornget project at

casual said...

You seem to have capitalization mismatch dependentassembly-dependentAssembly