Musings of Geekdom by Eric Newton

tail /var/log/thoughts
posts - 88 , comments - 41 , trackbacks - 68

DLL collision hell v2.0 in .NET

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 ;-)

Print | posted on Sunday, October 30, 2005 1:42 PM |

Feedback

Gravatar

# re: DLL collision hell v2.0 in .NET

Oh, I feel your pain. I'm starting to get really annoyed at how every open source tool in the world depends on a completely different version of log4net. I ripped out the log4net support in my open source project because it was conflicting with the dependency on NAnt's version of log4net for my custom NAnt tasks and screwing up our project's build. Argh.

I like your idea about the archive files.
10/30/2005 7:19 PM | Jeremy Miller
Gravatar

# re: DLL collision hell v2.0 in .NET

I solved this problem for my ORMapper by defining my own interface for logging -- then the user can implement that interface using whatever version of Log4Net, Enterprise Library, or homemade logging system they want. It also means that I don't introduce an unnecessary dependency.
10/31/2005 10:38 AM | Paul Wilson
Comments have been closed on this topic.

Powered by: