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)


Feedback was imported from my only blog engine, it’s no longer possible to post feedback here.

re: OpenWrap – A Package Management System for .NET - Robert Pickering

So it does that hornget is a bit more similar that I orginally thought, but it does seem to lack the msbuild integration that openwrap has. With Tim Robinson’s effort as well it does look like there’s now quite a lot of interesting stuff going on in this space. I guess a bit of competition will probably mean we end up with a nice package management system.

New NPackage binaries - Tim Robinson

I’ve shaved two yaks this weekend: Ported the NPackage install command to F#. There shouldn’t be any visible change in the application: rather, F# lets me write more succinct code for handling HTTP and package dependencies. (Specifically, I was able…

The Morning Brew - Chris Alcock » The Morning Brew #601 -

The Morning Brew - Chris Alcock » The Morning Brew #601

re: OpenWrap – A Package Management System for .NET - Steve Bohlen

I may be missing something in your description of OpenWrap, but I don’t really see how this solves the problem any more ‘fully’ than something like HornGet does (or attempted to do).

The issue that OpenWrap seems to fail to address is version-incompatibility between OSS packages. Simple example: if the ZIP with FluentNHibernate and the ZIP with Castle Windsor, and the ZIP with NHibernate each selected with the OpenWrap DSL aren’t in agreement with each other in re: what version of NHibernate, Castle, and others they all cross-depend-upon, all these OSS projects won’t be able to (co-)exist within the single solution into which you reference them.

OpenWrap would seem to solve the "central clearing house where I can get all (most) ZIP files for all (most) projects I might want to download" in a way sightly preferable to a page with bookmarks to each of them.

But I don’t see how it even tries to address the very next stumbling block most will face: "now that I’ve got all this stuff in my ‘local cache’, how the heck do I get it all into a single solution such that it will all compile and link properly?"

Unfortunately IMO (and experience), its only the lowest barrier to .NET OSS adoption that can be described as "wandering around from site to site trying to find the download". The real barrier is more about getting cross-compatible builds of all of them that are designed to compile against each other play ‘nice’ with each others’ dependencies.

From your understanding of OpenWrap, how do you see it addressing this problem better (or even worse, differently, etc.) than HornGet?

Just wondering. I see a number of these .NET "Package Management" projects continually crop up, but they never get anything beyond ‘package centralization systems’ and seem to languish without managing to address the most persistent roadblocks to OSS adoption that I’ve seen (and experienced personally).

re: OpenWrap – A Package Management System for .NET - Robert Pickering

Steve I realize there are many other barriers to OSS in the .NET/Microsoft space. I don’t believe I tried to claim otherwise in this article.

I believe openwrap’s versioning system is a little more suitable than hornget’s, specifying a minimum and maximum version, rather than just a version as you get with hornget, will give them a little more room to find compatible versions of everything. I think, this is just speculation, as I’ll freely admit I’ve not tried either system in anger.

Now, perhaps Seb, Tim and the hornget people would be better joining forces and working on one single package management system or perhaps, there better off working apart and letting natural selection pick the winner. Either way, Seb’s presentation really bought the problem back the for-front of my mind and I happy to see that several bright people working on smoothing out this problem.

re: OpenWrap – A Package Management System for .NET - Steve Bohlen

Yeah, FWIW, I too would love to see this solved, but fear that new attempts are not going to be any more successful that past ones :(

There’s a real reason why something like Ruby’s GEMS can work for an interpreted language but is very hard to ‘port’ as a concept to compiled languages: as run-time interpreted code vs. pre-statically-compiled code in .NET, .rb files are considerably more tolerant of ‘versioning’ than compiled assemblies :)

While its possible in an interpreted language to say "make sure you have something between v1.2 and v1.8" and rely on the packaging system to "just deal with it for you", its really an entirely different ‘animal’ when you’re talking about statically compiled assembly version(s) where 2.1.2 is completely incompatible with 2.1.1 from the perspective of the .NET run-time even if the contents (MSIL-wise) of the assemblies are otherwise 100% compatible but are merely given two different versions :(

That said, I’d love to see this solved so I wish any and all the best of luck; I certainly don’t claim to have all the answers, just that I’ve experienced most of the problems and so I’m merely curious how others are addressing what I consider to be some very real challenges to the frequently-suggested but rarely executed "Hey, wouldn’t it be great if there were a Ruby Gems equivalent for .NET?" sentiment.

I’ll certainly keep my eyes on the project; while hugely skeptical of its success, I none-the-less wish them the best of luck; if successful, it would certainly be a significant boon to the .NET OSS ecosystem/adoption space!

re: OpenWrap – A Package Management System for .NET - Sebastien Lambla


First and foremost, I’m afraid you have a couple fo things wrong, let me clear up those first:

1. OpenWrap is built to let you decide, when packages are conflicting in their dependencies, which ones you want. Maybe automatic downgrade is how the resolve should work, that’s also a possibility. No one, in dynamic, static, functional languages, can make code relying on code no longer there run, and OpenWrap can’t change that. It’s the job of open-source projects and package builders to keep up and re-release with new versions of their packages.

2. Versioning doesn’t work at all the way you seem tio think it does. Versioning is not respected by the fusion loader, ever, for unsigned assemblies. If you do not strongly-name your assemblies it doesn’t matter at all what version is running. If you’re strongly-named, then you need policy redirections, which are not a nice thing to have to work with. Solution is to simply strip the strongly-named signature from the assemblies when publishing them to OpenWrap.

3. OpenWrap does take care of adding references to all your projects when you depend on a package, that’s the first thing it started by doing.

I understand that negativity and scepticism is the usual motto of the cool kids in the .net world these days. I’m just building a package management system that fits my needs for openrasta. That’s why openwrap is not on my blog yet, doesn’t have a home page, and i’ve only presented it to small groups to get early feedback and listen to what they want.

If you have things you want, don’t hesitate to email me, we can chat and see if it fits or not.

re: OpenWrap – A Package Management System for .NET - Robert Pickering

Thanks for the clarifications Seb, still don’t know the OpenWrap system well enough to clear these matters up myself.