Treating Nuspecs as First-Class Citizens as Project Types in VS2012

Topics: Ecosystem
Mar 20, 2013 at 2:35 AM
Here's something that I've been thinking through over the last two years working with NuGet.

I've done a lot of demos for user groups and sessions at conferences, and have helped get our corporate feed going (an internal one based on NuGet Server and a MyGet one) so that NuGet is how we distribute our extensibility points for our products.

I've built a lot of packages - mostly targeting our corporate feed, but many to help others get started as well - and written a ton of install scripts. I've incorporated msbuild steps and recently started using the NuGet bits on TeamCity.

The one thing I keep seeing over and over again is that devs are looking for the golden moment when making a new NuGet package is just as easy as the File -> New Project experience.

So, thinking out loud as to what that might mean:
  • Project that lives in the solution side-by-side with the projects that you're going to be distributing, the project "output type" being the nupkg
  • Tooling in Solution Explorer that allows you to specify project outputs that are to be included in the package
    • An example might be...right click on a DLL project, select "Add to Whatever.Nuspec...", select which DLLs to include. Automatically adds appropriate package/framework assemblies
  • Tooling in VS, such as a project property page, that allows editing the nuspec via GUI
  • IDE support for intellisense on the nuspec itself as well as powershell scripts and in any config or pp transforms
  • Install/Uninstall and Tools scripts could become testable in the same project (not sure what that looks like, but sounds good!)
  • An in-project feed server that is updated with the package at build time to facilitate easier testing. Similar to the VS internal http server, so I get a feed for "Free" when I add a NuGet project to the solution on some free port
  • Versioning support and tools/scripts/directives/SOMETHING on how to increment your build number/package number automatically following SemVer
  • Publishing as part of build configuration (like, when I build in Release mode), with a prompt to confirm the push, version numbers, etc.
There are three things I'm finding I'm typically doing when building packages:
  1. Creating a library that may or may not have dependencies
  2. Building out some kind of "merge/transform" project, like a kick-start for plugins, MVC projects or something that, for example, consumes a series of webservices
  3. Writing powershell scripts to support 1 & 2 above
So, there's a start. Not all my ideas here and not all are good, but certainly could help depending on how you build and use packages, and perhaps how frequently you use packages.

Is anyone else interested in seeing something like this?

Cheers.