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.
