Dru Sellers - http://codebetter.com/blogs/dru.sellers/
http://codebetter.com/blogs/dru.sellers/archive/2010/07/29/ilmerge-to-the-rescue.aspx
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:
Magnum.dll
Magnum.FileSystem.dll
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:
NHibernate.dll
Antlr3.Runtime.dll
Iesi.Collections.dll
log4net.dll
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
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:
MassTransit.dll
MassTransit.Infrastructure.dll
MassTransit.Transports.{YourTransportChoice}.dll
MassTransit.{YourContainerChoice}.dll
{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:
Post a Comment