Trove

Over the last couple of months I have been thinking about package management in the .net ecosystem. If you only develop using assemblies from Microsoft then you will not have had to think much about this but if you utilize open source assemblies then it can rapidly become a real bugbear. Some open source packages are standalone and thus don’t suffer reference problems; the HtmlAgilityPack is a good example of this as it only references the System assemblies. If you start utilizing the Castle Project (the IoC functionality in Windsor or the NHibernate functionality in ActiveRecord are commonly employed) then you will rapidly encounter reference problems, especially if you also use other libraries that also depend on Castle.

Now I’m not the first to consider this problem. HornGet takes the direct approach of building the source and publishing the binaries. I don’t know how much, if any, verification work is done but I have noticed that the builds seem to break rather frequently which doesn’t inspire confidence. As an experiment, I decided to carry out a poor man’s replication of that approach by simply writing a batch build file of a sequence of projects. One of the first issues I discovered was that the trunk often doesn’t build successfully on open source project. I suppose that I should not have been surprised, of course. I then carried out a second experiment, building from branches where available. This typically built successfully but the dependencies were incompatible, leaving you choose this or that rather than this and that. So my conclusion was that direct build doesn’t meet the need.

After direct build, there is Ruby Gems envy. I’m convinced that there was an NGem project at one time but I can’t find it and it certainly didn’t get any adoption by the community. At present I’m aware of at least three projects that want to create a solution to the problem: OpenWrap, Bricks, and CoApp. The problem is that all of these are either vapourware or alpha code and I want something useful right now.

After musing for a little while, it was clear to me that simply starting yet-another-package-management-project would be wasteful duplication. Maybe one of the currently active projects will come to something, who knows. I then got to thinking about what would be the simplest thing that could possibly work? ^{(Ward Cunningham)}. Well, maybe the simplest thing would be just to work on a single package of mutually consistent assemblies. Not so hard to do either, so long as you put together some verification tests to check that the package as a whole is stable and mutually dependent. How to distribute? An easy way would be just zip up the assemblies to share that but then it occurred to me that I could simply create a Subversion repo and consumers could simply link to it using svn:externals which is really simple to configure with TortoiseSVN.

Thus was born http://code.google.com/p/trove/

There is a manifest of the contained assemblies. All you need to do is add an svn:externals property on your lib folder of “trove http://trove.googlecode.com/svn/trunk/lib” and update :-)

If you pull down the whole project, you will also get the verification tests.

At the moment, the trove contains:

• Antlr3
• Autofac
• C5
• Castle (ActiveRecord, Logging, Transaction, Validator, Windsor and some Facilities)
• Cavity
• CommandLine
• CommonServiceLocator
• Fitnesse
• Flee
• FluentNHibernate
• FluentValidation
• HtmlAgilityPack
• IesiCollections
• Json
• LinFu
• log4net
• Lucene
• MathNet
• MEF
• Moq
• NHibernate
• Nini
• Ninject
• NLog
• NMock
• NodaTime
• NUnit
• PowerCollections
• RhinoMocks
• SQLite
• StructureMap
• SubSonic
• Unity
• WCF REST Starter Kit
• xUnit

If there are other libraries you think I should have in the trove, please let me know.