Should self-created NuGet Packages be placed in version control?

Question

I have started creating NuGet packages for some frequent dependency projects we used to use svn:externals for in our ASP.NET solutions. I'm hosting the .nupkg files in a network folder, and using that folder location as a NuGet feed.

I'm unsure what files to place in version control and where. Do you put both the .nuspec AND the .nupkg files in your repository? Do both the .nuspec and .nupkg file go in the project's version control? I thought since the .nuspec file generates the .nupkg file, you'd only need that file in version control. But, I was also thinking it might be a good idea to make the network folder, that I'm using as a NuGet feed, a repo in itself. Then I can version control the .nupkg files.

What are some good practices for version controlling created NuGet packages?

Answer 1

I'm in the same place you are. In keeping with the idea that you don't commit any file that you can build, my .nuspec files go in version control, but the .nupkg files don't.

Since the version number is incorporated into the .nupkg file name, you can have distinct versions of the package in the repository at the same time. You either need to either use the <version>$version$</version> form in the .nuspec file, and set the assembly version to auto-increment, or just manually change the version number each time. You could then make a Subversion tag on that version number, so you could get back to the source for a particular package version if you need to.

In order to let client projects automatically incorporate minor bug fixes in our packages, we're going to enable NuGet Package Restore in the client projects, and publish packages with short, fixed version numbers, like "1.2". When there's a simple bug fix for the package, we'll re-publish with that same version number. That will overwrite the prior version in the repository; client projects will then get the update when they restore packages during the build step.