I have a UWP Project with some nuget packages installed, NuGet now downloads and stores a copy of the packages in a global packages folder located in my %userprofile%\.nuget\packages folder. I want to move My project into another computer, How Can I move it with packages this project needs to? I don't want to search in that folder and find the desired packages and move them too, I want the packages stick in my project
You basically don't need to do anything. As you have figured out, Nuget stores a local copy of those packages in your project, so if you open that up on a different computer, all you have to is to right-click the solution and choose "Restore NuGet Packages" to have those loaded. It will then create a global cache of packages for you.
Or are you asking how to disable the global package cache?
Related
I would like to use NuGet to avoid adding a 3rd party executable to git repository.
I have a NuGet package with executable published to our NuGet source. Package contents:
content\SetupFiles\bigexecutable.exe
I've added the NuGet reference to the project in which I want to use the executable. It properly adds the
SetupFiles\bigexecutable.exe
to the project directory during the NuGet package installation. But if I delete the file from the project directory it is not replaced during the build.
Is it possible that NuGet would verify if the package contents are present before the build and reinstalled the package if something is missing?
Your .exe is being added to the project since you are including it in the Content directory. NuGet will not restore items into the project. It will only restore items into the packages directory.
An alternative would be to create a tools NuGet package where the .exe is not added to the project but is available in a tools directory relative to the solution's directory.
The NUnit.ConsoleRunner is one example of such a NuGet package where it has all its .exe files in the tools directory. Using the tools directory does not cause NuGet to add any files to your project.
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 server & NuGet gallery both in version 2.2
I want to update them to 2.8.1, without loosing all my packages and changes I made in the website.
Is there anyway to do so?
Thanks
I would suggest you make a copy of the code/service/web.config files that you have now as a backup. Then open the manage nuget packages dialog, go to update tab, and then click Update All.
If NuGet detect that the package's files have been modified, it will pop up an File Conflict Dialog to ask you if your current files (such as code files) etc. wanted to be overwritten, just answer No to preserver your original files.
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.