views:

350

answers:

3

Specifically, how do you handle 2 different libraries sharing a common dependency?

For example, I've structured a project with a Lib\ directory with each 3rd party library (and its dependencies) contained in separate sub-directories:

Lib\
   IBatis\
   Log4Net\
   etc.

This is fine if there's no overlap. Required libraries are added implicitly to the bin\ directory.

However, I'd like to start using Castle Windsor as a DI framework. Both iBATIS.NET and Castle Windsor use Castle.DynamicProxy.dll. When I do a build the Castle Windsor dll is copied over. I'm not sure if this is just coincidence, or if it's being chosen because of the file version - the assembly versions are both 1.1.5.0, but the file version is greater (1.1.5.4333 vs. 1.1.5.0).

In general, what's the best strategy for including 3rd party libraries that have common dependencies? Is it possible to somehow include both?

Edit

I've settled on a single lib/ folder where all the required dll's get referenced from in the projects. I keep a separate ref/ folder where they're sorted by project (eg. NHibernate, log4net, etc.) and version. It's overkill, but I can see at a glance which libs I'm using, test out new versions easily and copy back older ones easily if necessary. This can potentially make the project grow very large in size (just to keep all these reference libs) so once I'm settled on a given version of a library I clear out the older one. It ends up looking something like this:

lib\
   IBatisNet.Common.dll
   IBatisNet.DataMapper.dll
   log4net.dll
   ...
ref\
   IBatisNet\
      1.6.1beta\
      1.6.2\
   Log4Net\
      1.2.10\
   ...
+2  A: 

You cannot include two copies of the same DLL, so you will want to pick a version, and build/test both tools against the selected dll file.

Mitchel Sellers
A: 

If you've got source to all of the dependencies, I like to have a .sln that builds all of the projects, with project references to each of the dependencies. VS.Net seems to handle the "which version" issues quite well at that point.

Joe Hildebrand
+1  A: 

For 3rd party libraries that don't install to the GAC, you can place them on a common network resource, and then override the AppDomain's assembly resolve event to load them from this common location.

You can then turn off the "Copy Local" setting and have some control over where to load them from.

Dave Moore