Just downloaded the latest NHibernate version 1.0.0.0 from Sourceforge.net.
My only concern is the baggage with it, in terms of extra dlls that will have to carry through if the NHibernate.dll is referenced. I suppose an ILMerge is in order, basically at my own leisure.
But considering the fact that I might actually have referenced this Castle.DynamicProxy dll in a project in the same solution, I'd get a DLL conflict. In theory, I could simply upgrade my project file to use the same reference to prevent that DLL collision. But consider a major/minor version conflict... either I'd have to upgrade my code to work with the NHibernate Castle.DynamicProxy version or vice-versa, and all the potential problems therein.
Another aspect is using log4net. I love log4net. But again, what if NHibernate uses the “wrong” version of it, versus the 3 other projects of my own that use, say version 1.1.0.0...
In a sense, our DLL hell problem has morphed from COM Registry ProgId collisions to DLL file name collisions. Perhaps the framework runtime guys should consider the option of being able to package these DLLs together, similar to Java's JAR's (I believe). The great thing about the JAR's are being able to package the reference (NHibernate) with its own versions of the DLLs that it needs (log4net, Castle.DynamicProxy, Iesis.Collections, etc)
So I guess for .NET Framework v3.0, hopefully we'll see NAR's (.NET archives) or DAR's (DLL archives)... and with that the inevitable “you copied Java!”... yeah probably, but it seems that all the good ideas are copied anyways ;-)