Should standalone NuGet packages be created in version control?

Question

I started creating NuGet packages for some of the frequent dependency projects that we used to use svn: externals for our ASP.NET solutions. I place the .nupkg files in a network folder and use this folder as a NuGet feed.

I am not sure which files to place in version control and where. Do you put .nuspec and .nupkg files in your repository? Do the .nuspec and .nupkg file in project version control? I thought, since the .nuspec file generates the .nupkg file, you only need this file in version control. But I also thought that it might be a good idea to create a network folder that I use as a NuGet feed, the repo itself. Then I can manage the versions of the .nupkg files.

What are some good practices for version control of NuGet packages?

Answer 1

I'm in the same place. In keeping with the idea that you are not creating a file that you can create, my .nuspec files are included in the version control, but the .nupkg files do not.

Since the version number is included in the .nupkg file name, you can have different versions of the package in the repository at the same time. You either need to use the <version>$version$</version> form in the .nuspec file, or install the build version to automatically increase, or simply manually change the version number each time. You can then make the Subversion tag on this version number so that you can revert to the source code for a specific version of the package if you need to.

In order for client projects to automatically include minor bug fixes in our packages, we will enable NuGet Package Restore in client projects and publish packages with short numbers with a fixed version, such as "1.2". When a simple bug fix is ​​fixed in the package, we will publish it again with the same version number. This will overwrite the previous version in the repository; client projects will then receive an update when restoring packages during the build phase.