NuGet for Applications

Topics: General
Oct 16, 2014 at 10:56 AM

ASP.NET vNext has a KPM Pack command that publishes an application ready for deployment. I submitted a proposal that, instead of producing a folder structure, it could produce a NuGet package. The issue summary explains the reasoning in depth:

Chatting through the issue today with @davidfowl, it seems that the idea of KPM Pack producing some kind of package - a ZIP file with metadata describing the contents - is quite agreeable. Anything has to be better than a folder structure with no metadata.

The debate centres around whether NuGet is the appropriate package format for applications, as opposed to libraries. So I'm moving the discussion here :)

While NuGet is obviously intended to be used for .NET libraries and dependency management, the reality is that today it's already used for much more:
  • Chocolatey (and OneGet by extension) use NuGet packages with their own conventions for installing applications
  • Octopus Deploy uses NuGet packages with our own conventions
  • Tools-only packages like NUnit.Console, which install at the solution level and are just EXE's without DLL's
  • Orchard and plenty of other projects use NuGet packages to manage plugins and extensions
  • JavaScript and other packages that arguably shouldn't be on NuGet
To me, the consensus would seem to be:
  • The effort involved in building a totally new package format, repository protocol, and all the ecosystem (build tool support, etc.) around it etc. is too high
  • NuGet.Core (the layer that doesn't make assumptions about package contents, adding DLL references, VS plugins, etc.) is perfectly suited to the job
  • Applications don't belong on the repository
  • Whatever we do, it shouldn't make it harder for the NuGet team to innovate or get in the way of their focus on being the .NET package manager for libraries
My proposal is simple and starts by involving no effort from the NuGet team:
  1. People using NuGet for applications should put their application in a folder in the root called app. Under that folder, anything goes, it's up to them and whatever deployment tool they use to make sense of the app.
  2. Application packages should never be published to, so they don't pollute searches in Visual Studio
The simplicity should allow room later to make changes if things become a problem:
  • In the same way as target framework filtering examines the lib folder to determine if a package makes sense to show in VS, you could exclude packages with just an app folder.
  • could even reject package pushes with the app folder at the root
I totally understand you're busy with NuGet 3.0 (which by the way, going from the blog, sounds awesome!) so I've prepared some replies ahead of time:
  • "Sounds great, all the best, you have our blessing to use an app root directory in packages, and use NuGet.Core, just make it clear that these are application packages and don't belong on cluttering up VS"
  • "No, NuGet and applications just don't mix, go find another package format"
  • "We have a way better idea, and we'll tell you once we aren't busy with NuGet 3.0"
Oct 17, 2014 at 9:30 PM
Short answer: We're starting to think about this more now.

Medium answer (close to your first option): Working against an \app folder in the package seems like a pretty good approach. You mind partying on that for a little while and reporting back how it's going. From what I've seen so far, it seems to be promising.

Caveat: NuGet.Core is cool for now, but it's going to die a fiery death at some point. We'll have a new NuGet.Packaging that is strictly for the scenarios of consuming (and maybe producing) packages that you already have on disk. We'll end up with better client libraries for consuming feeds too.