OpenWrap – A Plan for MSBuild Compatible Package Manager for .NET
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.
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.
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.