My little demo/test application that I monkey around with from time to time got a major revamp today.  Nothing fun or exciting, just a lot of infrastructure cleanup that I've been needing to do for some time.  I was hoping this would only take me an hour, but in reality it took me 3 times longer than that.  All I needed to do was:

1. Upgrade NHibernate from 1.2 beta3 to NHibernate 1.2 GA.
2. Separate out my shared core library into a separate folder/solution structure.
3. Stop using GAC'd Castle and NUnit assemblies and use a local libs folder to facilitate building on a clean box.

Nothing fancy, but I ran into some serious issues with log4net.  You would think that because most open source projects use log4net, integration of multiple open source products that use log4net would be a breeze right?  Well, Castle RC2 uses log4net 1.2.9.0 while the latest NHibernate release uses log4net 1.2.10.0.  That seems fine, just add an assembly binding redirect to have castle using the newer log4net version right?  Well that's fine until you realize that the log4net team unexplicablly changed their signed key between those releases, which means you can't use a binding redirect.  Oops, I doubt the log4net team intended that to happen.

To get around this version mismatch I ended having to grab the latest code from the Castle subversion repository which included log4net 1.2.10.0 and build my own assemblies that would play nicely with  NHibernate.

The moral of this story is don't change your keys between versions if they're binary compatiable/incremental updates.  Especially for something so commonly shared as log4net.