OpenWrap – A Plan for MSBuild Compatible Package Manager for .NET

Posted by Jonathan Allen on May 26, 2010

Sections

Development,

Operations & Infrastructure

Topics

.NET ,

Package Managers

Tags

Bricks ,

OpenWrap ,

WebGAC

Package managers are well known in the Linux world where the need to bring in dependencies from a wide variety of sources is important. A good package manager provides a unified way to obtain a library or application with the correct version of all its dependencies no matter what their source. For Ruby programmers the most popular package manager is RubyGems, while over on the Perl side we have the CPAN module, which is hosted on the Comprehensive Perl Archive Network.

For .NET developers there isn’t really an equivalent. Even if one sticks to just Microsoft components, the libraries are scattered across Microsoft’s many web sites as well as independent sites such as SourceForge and CodePlex. And with the increasing trust in non-Microsoft projects such as Castle Windsor and NHibernate the problems are compounded.

In a presentation at Progressive.NET, Sebastien Lambla introduces OpenWrap, a project designed to focus on managing dependencies in binary form. Robert Pickering summarizes how OpenWrap will 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 centralized cache on your local machine. This centralized cache will then be used to provide the references required to build you’re project.

This isn’t the first package manager to try to make inroads into the .NET ecosystem. There is also the recently announced Bricks project, which is currently a command line tool, and WebGAC, which for some strange reason requires Apache.

As it is still in its infancy, OpenWrap still requires manually editing the project file to call OpenWrap instead of the C# compiler. By listing dependencies in the “wrap descriptor” file, the necessary DLLs are automatically downloaded and added to the project. Because the references are being managed by OpenWrap, they do not appear in the references folder of the solution explorer.

The wrap packages are based on the ZIP format. Besides being a well-known format for Windows programmers, it has the benefit of being extensible due to the way its header information is stored at the end of the file. Beyond that is considered dead space, making it an excellent place to store digital signatures.

1. Back to top

   NPanday

   by Brett Porter

   Another alternative to consider is NPanday, which brings Maven-style dependency management into .NET builds. This runs under Maven (so requires a JRE) for the resulting build, but will build both MSBuild-based and independently (POM) configured projects with the Maven lifecycle (using csc, etc). It integrates with Visual Studio to provide a way to resolve references from a Maven repository and add to both the POM and MSBuild project.

   Reply

2. Back to top

   Re: NPanday

   by Jonathan Allen

   That brings up an important point. Why does every package manager need to written in the same language as the language that uses it?

   Reply

3. Back to top

   hornget

   by Koen Williame

   Another alternative that seems to have the same goals as this one is horn.
   They use boo as their DSL language for defining packages, and tried (or are trying, I don't know the status) to agree with opensource projects like nhibernate on a common structure by which horn could automatically get the necessary information to include them in their system, using their repository directly instead of maintaining a separate one of their own, which is what openwrap proposes if I understood it correctly.

   Reply

4. Back to top

   Re: NPanday

   by Adam Mills

   The integration into VS sounds nice. Why not use Gems?

   Reply

• Older >