OpenWrap vs NuGet [closed]

Question

What is the difference between OpenWrap and NuGet. And what you prefer ?

Pipe

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.

Mesolithic

openwrap.org (its homepage) is busted, wiki pages hacked and has seen no commits for 3 years. In OSS world, that translates to something being dead! – Macbeth

Well yes, but then you comment on a post dating back from 11. Nuget tooling has won, nothing to see here, move on. – Kimura

Shouldn't you update your answer then? Honestly IDK why this question is kept open even, it doesn't follow SO guidelines anyway. I added the comment as a help, just so that it may save future visitors time. – Macbeth

I don't tend to go and edit questions years on, it's poor form is it not, rewriting history n all that? It had value and truth at the time it was answered. If it breaches SO guidelines, back in 2010 or today, or it must be close or what not, I'm sure someone can happily go and do that, I have no idea what either of those issues may be. – Kimura

SO is a strange place in that regard. I even get downvotes on old answers since they are outdated today. Thought of warning you before those bandits catch up with you. :) – Macbeth

Answer 2

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.

Content

Again Phil, I will reiterate what I've said many times before. You do not have to ship any part of OpenWrap as part of the result of a build. OpenWrap includes itself inside the build to add references when requested as opposed to muck around with csproj files directly, and that is the only difference at build time. We support runtime too, if thats what people want. – Kimura

Seb, I never said Open Wrap did, but I can see that my last statement suggests it does. I've clarified the point based on your comment. Thanks for clarifying that to me! – Content

As of now usablity of nuget package is tied to the nuget version which in turn is tied to visual studio version thus hindering ability to use packages even if the dlls are directly usable in vs – Carpal

Answer 3

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.

Taverner

See response to Phil. You obviously haven't used OpenWrap much to assert that I somehow lock people in and force them to distribute OpenWrap as part of the result of a build. Especially considering that both tools can run side-by-side without a problem, and that OpenWrap supports NuGet packages but not the other way around... – Kimura