Merge separate DLL's into a single assembly for open source distribution

Question

I have written a lib that I am about to publish open source. It uses MS Unity. Should I merge the Unity DLL's (Microsoft.Practices.Unity.dll & Microsoft.Practices.ServiceLocation.dll) into the OS lib using ILMerge, should I simply ship the DLL's along side the OS DLL or neither?

Answer 1

I wouldn't merge the lib and MS Unity.

As MS Unity is under the Ms-PL license, I would ship the good version of the MS Unity assemblies along with the lib. Don't forget to include a readme.txt file with the license of MS Unity.

Answer 2

I wouldn't suggest you to merge any 3rd party libraries into your one. The reason is simple: by doing this you restrict your users from using another (or possibly custom) versions of these 3rd party libraries.

I would recommend to ship these DLLs along with your libraries as long as include NuGet package reference to the solution (if it is an opensource library). This is recommended for any 3rd party libraries, but for things like IoC containers, loggers and other commonly used concerns you generally want to provide users with some more flexibility.

If your library is supposed to be used by many then you can predict that someone would prefer to use another container, Perhaps, these other containers are already used in their applications when they want to start using your library. It is hard to imagine that your users will be happy to give up on what they use and start using Unity instead, or support two containers. I would recommend you to abstract these dependencies away and give your potential users a choice.

For example, in your library you can define an interface IContainer with all the methods your library needs from the container (Resolve, Register, etc). You can also implement another separate DLL: SuperLibrary.Container.Unity.dll which will contain an implementation IContainer that works through Unity. Now, if I want to use Autofac in my project along with your lib, I would be able to create my own SuperLibrary.Container.Autofac.dll, which will possibly contain one or two files for your IContainer implementation, and be a happy user of your lib because I use my Autofac and don't need to know anything about any Unity :)

Or even you, if you decide to be nice enough, you may ship separate dlls for Autofac, Unity, Unity2, StructureMap, Spring.NET, etc to make your users happy by giving them a choice of which library to use.

Answer 3

I suggest to write an instruction how to get exactly version of Unity using NuGet package manager. It should decrease a headache of end users.

Also provider a link to Unity download page with specifying compatible Unity version(s) list.