Friday, July 30, 2010

ILMerge to the Rescue?

I have talked about the merits of Ilmerge in the past ( and here is an interseting article by Dru Sellers on the topic.

Dru Sellers -

As I continue to work on the 'nu' story, one of the things I am thinking about a lot is how we are going to make this happen. Last week I also had the pleasure to spend some time talking about version management with Udi Dahan and Chris Patterson while they were both in Kansas City. While we discussed a variety of topics one of the things we discussed was how to manage dll dependencies. After this discussion I have come to my current 'thought.'

We should use ilmerge internal more. I have no doubt it has its issues but let me work this out. And then you can tell me what you think.

I am currently working on a new area of the Magnum project that is adding a nice abstraction on top of the file system. One of the features is handling zip files. For this I am using a third party library to handle all that nastiness. It was been a pleasure so far to work with. The problem is that in order to use this you now have to reference 3 assembilies:

Ionic.Zip.dll (DotNetZip)

So, some of this is due to the Magnum core philosophy that we are going to take dependencies with this library. So because I want to use Ionic.Zip I have to now have a new dll Magnum.FileSystem. That's fine but adding 3 references sucks. Not only that but I now have to add a new gem dependency for magnum as well. :( As I thought about this it occurred to me: "Why does the user care about Ionic.Zip?" the user never interacts with this library and if I replaced it with the next hot thing you wouldn't even know. :) Ok, so what if I just 'ilmerge' this bad boy in. What would happen? Well I think I would have fully encapsulated my code. And if I ilmerge internal it, you could actually use your own version of 'Ionic.Zip' and we wouldn't conflict with each other! How cool is that? Once, I have ilmerged that in I can probably just either drop the Magnum.FileSystem project or I can just ilmerge it in to Magnum as well. Suh-weet.

So lets take a second and think about what this would do for us as a process. Lets look at NHibernate:

YourByteCodeProvider and its dlls

NHibernate.dll of course that guy is going to stay around, he's the beef! What about Antlr3.Runtime.dll? If you are going to use Antlr3.Runtime in your own project do you want to be limited/constricted to whatever NHibernate is using? I would think not, so that puppy gets ilmerged in. Iesi.Collections? Gotta be honest, I should probably use more set based classes, but I don't; and when I do I use HashedSet which I am pretty sure NH supports at this point. But because this dll isn't fully encapsulated, I am pretty sure we can't just absorb this guy in. Question? Why don't we just merge the Iesi code base into NHibernate, I have never used it outside of NH. Have you? Last we have log4net, the venerable work horse of logging. This is another dll that I see us having a hard time with, we could merge it in, but configuring it would get interesting and I really like the log4net story. So that gets us from 4 -> 3 dlls. Not to much of a win.

So lets take a look at MassTransit. A fully configured MassTransit setup (at least as of now) could put the following dlls into your mix:

{YourContainersStuff}.dll (from 1 to possibly 4 dlls)

That a whopping 5 dlls, and if you use the saga support that is another 7-8 dlls, bringing the total to what could be 13 dlls. Schnikeys!

So as you can see, its not a 100% win, but I THINK the idea is going in the right direction. Framework builders, lets try to encapsulate our dependencies and ilmerge internal them. It will give our users a better experience and should make our out of the box experience that much better.

Please let me know what you think. Is this trash? Or is it good?

No comments: