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?
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.
Related
Quite often when installing some of the js* library packages nuget copies js files to Scripts directory of the web project and puts these files under source control.
Yet while updating the package instead of just rewriting the files nuget first removes them and then copies new versions. Because of that TFS shows the error about conflicting state: Files are scheduled for removal but present locally.
Can we somehow change this behavior or is it completely defined by the author of the package?
No, this behavior is not defined by the package author.
And since NuGet 2.5, it is allowed to overwrite content files that already exist. Check: https://docs.nuget.org/release-notes/nuget-2.5
You need to use the Update-Package command to update NuGet packages.
We have a custom NuGet package which contains a DLL and a config file. We make use of NuGet package restore so our packages are not commit in to Perforce. When the package is installed to the solution it adds a reference to the DLL and the config file is included in the root of the project. Both of these are desirable, but should the config file be checked in to source control?
Our CI environment breaks when the file is not checked in, but the package has been downloaded correctly. It looks like this is the correct NuGet behaviour, but I'm not sure what the suggested best practice it is with regards to content files and how they should be treated in version control. Do all content files added from packages need to be checked in?
NuGet package restore will only restore files into the packages directory.
Files that are copied into your project when installing a NuGet package should be checked into source control since they will not be restored.
I have a local nuget repository, where I would like to browse the packages, is there some kind of tool for this?
We have a project that is pushed to my local repository, when we have new updates we just push a new version. We needed to branch the project and therefor we pushed this new version. But I somehow didn't change the package id. So now I need to browse and remove this package, change the id and push it again?
So my questions is, is there any tool I can use to manage my local nuget packages?
I'm not aware of any 'tool' to accomplish this. However, you can manually remove the .nupkg file for the latest (bad) version from your packages folder.
Since you are running the repo from IIS, you can check your web.config file for the following key:
<add key="packagesPath" value="C:\folder\folderHoldingNupkgFiles" />
This will tell you where you .nupkg files are stored. Go there and find the latest version that you published and remove it. Afterward, change the id, etc, and republish as the new package.
Once this happens, you should see the original/previous version from before, as well as you new/branched version.
I created a nuget package (let's name it Web.Content) with lots of js, css and other content for my other package (named Web). In nuspec file I had file section
<file src="Content\**\*.*" target="content\Content" />
I made changes in some files from Content folder, then I created a new version of Web.Content package.
I have a project that includes Web and Web.Content packages. After a new version of Web.Content package was created I updated it in my project via nuget. When I try to commit changes of my project, SVN suggests me to commit all content of Web.Comment package.
As I understand, when nuget package was updated all target folder "content\Content" was deleted and copied from package again.
But I need SVN to trace only changes that were made in a couple of files, I don't want to see thousands of changed files because actually changes were made only in some of them.
How can I make nuget copy only changed files? Should I change my nuspec file or should I create some PS script for my package that will override delete'n'copy nuget package update behaviour?
It will be great to have some examples or links.
Tried with NuGet 2.6.40627.9000 and Tortoise SVN 1.7.7.
As far as I understand NuGet copies files during package installation using somу VS API. This API makes SVN think that the file was deleted and a new file was added(probably this happened because VisualSVN or AnkhSVN is installed).
So we decided to do the next steps:
Place our content items in our own folder which name differs from
"Content"(let's name it "fs_content") because the presence of such
folder in package triggers NuGet usual installation behavior, but
we don't need NuGet to install our content in usual way.
Write own install.ps1 script that copies our content files to
destination and put it into Tools package folder.
But after installing such package our content items did not appear where they should appear. My colleague googled some information in NuGet help - "The package must have files in the content or lib folder for Install.ps1 to run. Just having something in the tools folder will not kick this off." We placed a dummy file into "Content" folder and Install.ps1 script began to copy our content from "fs_content" folder as we want.
Now SVN determines only changes made in some files correctly.
i understand that nuget's package restore downloads and 'installs' the various required packages before building a project. but i can't work out what purpose this actually serves.
as far as i can tell, the 'installation' of a package during the package restore, isn't the same as a package's actual installation - for example, if you do the following:
install the jQuery package (NOTE that this adds jQuery script files to your project's 'Scripts' directory)
delete the added jQuery script files
delete the 'packages' directory (steps 2 & 3 simulate the state on a build machine, or other dev's machine)
do a build (triggering a package restore)
at this point the build states
2> Successfully installed 'jQuery 1.9.1'.
however, the jQuery package's script files are NOT added to the 'Scripts' folder, and the files are NOT added to the project.
this means that you have to check these files into source control anyway.
which also means that when you update this package, you have to manage adding/removing the new/old files (since different, versioned filenames are used). otherwise your 'Scripts' folder fills up with an endless history of versioned script files.
so, if you have to check everything in anyway, and you have to manually manage adding and removing files when updating, what exactly is the benefit of restoring the package on build? what purpose does this serve?
more to the point, why doesn't this serve the obvious purpose: automatically adding the package's files to the project?
Using NuGet Without Committing Packages to Source Control discusses the reason behind package restore.
Package restore means you do not have to check the packages folder into source control. Once enabled for your project it will download the packages and put them back into the packages folder at build time if they are missing. It will not, as you have found, add any package files to your project. In the case of jQuery all the files from the NuGet package are added to your project. Other NuGet packages however include one or more binary files.