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.
Related
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?
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.
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.