OpenWrap vs NuGet [closed]

Answer 1

OpenWrap is an open-source project providing for dependency management in applications, not only at build time but also at runtime.

As such, our features are targetted at dynamic resolution of dependencies, be it for composite WPF applications, web app development or system-wide utilities. This makes our implementation very different from what NuGet does.

So here are the things that are different (I'll probably forget a lot, but ah well).

• No dependency on visual studio, and focus on productivity at the command-line rather than in a UI
• No dependency on powershell, OW comes with its own command system that lets you develop, deploy and execute your own commands, be it from our shell (the o.exe tool) or from MSBuild itself.
• OpenWrap uses OpenWrap to build and deploy itself, and is xcopy friendly at every step of the way.
• Has a system-wide repository of packages, so you can deploy your utility commands once rather than once per solution
• Supports dynamic dependency resolution at runtime, should you want to do that
• Has an extensible package format, so you can create new types of dependencies in a package and have OpenWrap help you use them in your application
• Supports both OpenWrap packages and NuGet packages and repositories
• Stays well away from the complications of XML and OData, and goes for simple text-based DSLs that are easy and quick to learn
• Support integrated build, so you can build and package your solution in one go
• Supports custom repositories on a network share that you can publish to from the openwrap shell or the msbuild tasks
• Provides dependency levelling, automatically choosing which combination of versions of packages are resolved
• Resharper integration means that any change you do to your dependencies gets reflected in VS in real-time
• TeamCity integration means you can build, package and deploy your package using exactly the same process, from an MSBuild script or from the command-line
• Extensible builders means you can change how the build is triggered within OpenWrap
• Support for test runners and shipping tests alongside packages
• Uses supported MSBuild extensibility points to include assembly references, and leaves the code you built alone. Once you ship binaries, you have no openwrap code dependency, only at build-time.

That's just for the differences, as that's what you asked about, so I won't bother you with what we do the same as other package managers.

Answer 2

One of the key tenets of NuGet (and an important difference with OpenWrap) is that it doesn't try to change the way you work. Instead, it makes it much easier to do the things that you already do today.

Say for instance that you're trying to use a Foo library, which depends on a Bar library. Today, you'd have to manually find those libraries, copy them to your machine and add references to them. Then later newer versions will come out and you'll go through similar motions to get them updated.

In such scenario, both NuGet and OW will make it easy to bring in those references, but the key difference is that NuGet does it in a way that is completely non-invasive. i.e. it will get the binaries onto your machine and references them in the same way as if you had done it manually. After it has done that, your project file is completely 'normal', without any ties to NuGet at build or runtime.

What this means is that if you get some libraries via NuGet and put your project in source control, another developer is then able to use your project without needing NuGet at all.

The OpenWrap approach has merits as well, but to go that route, you have to be willing to be using OpenWrap all the way, and not easily be able to move away from it.

There are many other differences (like rich VS support in NuGet), but this is what I view as the most fundamental difference between the two.

Answer 3

Just wanted to chime in with some thoughts from the NuGet side of things. Seb leaves out a few details that are worth pointing out.

• While our primary UI is VS based, the core NuGet assembly doesn't have any ties to VS. The ASP.NET Web Pages product has a web-based package manager. I wrote a blog post showing one example of using NuGet to build a website that updates itself at runtime. http://haacked.com/archive/2011/01/15/building-a-self-updating-site-using-nuget.aspx
• NuGet provides a powerful PowerShell console. NuGet packages can add new commands to the console. See http://blog.stevensanderson.com/2011/01/13/scaffold-your-aspnet-mvc-3-project-with-the-mvcscaffolding-package/. As before, this is one client to NuGet and NuGet core doesn't require it.
• NuGet is available for install via the VS Extension Gallery and is very easy to get started with immediately.
• NuGet supports pointing the client at a directory (or network share) containing a set of packages and automatically treats it as a repository. So if you don't want to deal with OData, you don't have to. But we also include an implementation of our gallery so there's no need to manually deal with OData/XML in any case.
• NuGet doesn't require you to deploy any part of NuGet as part of your application. It stays hands off and is focused on automating the steps you would take without NuGet to acquire and deploy your dependencies. To be clear, as Seb points out, neither does OpenWrap. I just wanted to make it clear that NuGet doesn't require this as well.