At Progressive.NET one of the sessions I attended was Sebastien Lambla’s talk on OpenWrap. OpenWrap is a package management system for .NET projects. I’m excited about this project for a very simple reason: it’s something the .NET Open Source community desperately needs.
What is package management?
Package manager is basically a piece of software that allows you to install the software or components you need on to your system. In one sense in the windows world this is handled by MSI, but that’s only half the picture of a package management system; ideally a package management system would provide a centralised server that handlers allowing to query what the latest version of a package is and download that or any other version of a package. Since in general software is build using other packages then it would be nice if it would automatically handle downloading the complete depancie graph.
Why does .NET open source world need one?
Well, leaving aside the fact that every other open source development community has one, it is need because handling dependencies between packages manually is time consuming and painful. Last year I was involved in setting up a small new web project. Naturally, I was keen to try out ASP.NET MVC, and as I had more or less a free hand, I also wanted to use Castle Windsor, Fluent NHibernate, Linq2NHibernate and some of ASP.NET MVC contrib which would allow me to easily integrate my controllers into Windsor. Now, although once I had everything going these technologies certainly made life easier. However, getting them in place was not so simple, firstly, and it’s quite a minor point, there’s no centralised localation where all these items can be downloaded so you have hunt around various project hosting sites, such as sourceforge, codeplex, google code, and github to find all the relevant binaries. Once found, it’s then that all the real fun and games start. As each of these projects depend on the other projects you need to ensure that you have the correct version of each project and if you download the latest version of each project, it’s odds on that you will not. To add to the fun and games the projects with incompatible versions will fail in different ways depending on if they are signed or not. An unsigned assembly will always be loaded, as the .NET loader simply ignores the version, number if it’s not signed. This will cause a MissingMethodException if there is an incompatibility in the interface. If an assembly is signed then an incompatible version will simply refuse to load, yes you can mess around with loading policy in the app.config to force the .NET loader to load a different version, but this isn’t a fun or good solution to the problem. So in general you have to decide which projects are important that you have the right version, then find versions of the other projects that are compatible with them.
Is hornget a package management system?
No. While like hornget and it does solve a similar problem, it does it in a slightly different way. The hornget tool allows you to download the source of a particular project, along with its dependencies, to your local computer and build it from scratch. While this will solve many of your version compatibility problems there’s a couple of problems with this approach:
- Building can fail and is a time consuming process
- Control over the version your building is somewhat limited, though this may improve overtime
How does open wrap work?
Packages are stored as zips on a central server. OpenWrap provides a DSL that will allow you to specific which packages you want to use and which version of that package you would like (the syntax here is quite flexible allowing you to provide a minimum and maximum version). OpenWrap provides a set of msbuild targets that allow you to hook this DSL based description into your build process and, of course, visual studio. These msbuild targets will then take care of downloading the projects you require and there dependencies to a centralised cache on your local machine. This centralised cache will then be used to provide the references required to build you’re project.
How can I get involved?
Simple. Download the source. Try it out. Talk to Seb to contribute feedback, packages and patches to improve and grow the functionality. There is much work still to be done.
So I hope that this article has convinced you a package manager is need for .NET. Is Seb the man to pull it off with his OpenWrap system? I certainly hope so, definitely a project to keep a close watch on.
(Other info about the stuff at Progressive.NET to follow shortly)