With newer versions of NuGet it is possible to configure a project to automatically restore NuGet packages so that the packages folder doesn't need to be included in the source code repository. Good.
However, this command adds a new .nuget folder and there is a binary there, NuGet.exe. This can also be re-created automatically by Visual Studio and so it doesn't feel correct to add that to version control. However, without this folder Visual Studio won't even load the solution properly.
How do you people deal with this? Add .nuget to source control? Run some command line script before opening the solution?
This post is old, you should not be using solution level NuGet package restore anymore. As of version 2.7+ there is an option in the NuGet setup to automatically restore packages on build.
So the .nuget folder can be deleted and the option removed from your projects.
http://docs.nuget.org/docs/reference/package-restore
UPDATE: With the release of NuGet 4.x and .NET Standard 2.0, when you use the new csproj format you can now use package references, ironically reintroducing the dependency on msbuild to restore packages, but now packages are a first class citizen of msbuild. The link above also makes mention of the PackageReference, but the following announcement details it better:
https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html
And the NuGet 4.x RTM announcement, which ironically isn't as useful:
https://blog.nuget.org/20170308/Announcing-NuGet-4.0-RTM.html
UPDATE 2: Apparently with VS2017 you can even use package references with classic csproj projects, but they aren't backwards compatible anymore, and there have been some problems with restoring package sub-dependencies. I'm sure that will all be resolved.
#Richard Szalay's answer is right - you don't need to commit nuget.exe. If for some reasons Visual Studio does not automatically download the nuget.exe, make sure you have the following set to true in the nuget.targets file:
<!-- Download NuGet.exe if it does not already exist -->
<DownloadNuGetExe Condition=" '$(DownloadNuGetExe)' == '' ">true</DownloadNuGetExe>
Close the VS solution, reopen it and build it. Visual Studio should download nuget.exe automatically now.
According to this thread, the .nuget folder should be version controlled.
You need to commit .nuget\nuget.targets, but not nuget.exe. The targets will download the exe if it doesn't exist, as long as you change DownloadNuGetExe to true in nuget.targets
Although I usually don't like the idea of adding exe's to source control, I would suggest that source control should contain anything that is required in order to open, build and execute the project.
In this case it sounds like the .nuget folder is a required dependency. Therefore it ought to be under source control.
The only question left, that you need to research, is how NuGet is going to react if that folder is marked read-only, which TFS will do once it has been checked in.
Update:
I did a little more research on this as I've never used NuGet before. http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html
I would suggest that probably what you want to do is make NuGet a requirement that has to be installed on every developers workstation.
Further, you should place in source control the batch file required to get a workstation ready to start editing the project. The batch file is going to run the commands necessary to get and install the dependency packages.
Beyond that I'd say you might want to contact NuGet directly to ask them how, exactly, this is supposed to work.
Now that nuget supports package restoration we're looking at it more closely.
We use Subversion for source control, and my initial thoughts are that .nuget should be added to our repository, but added using svn:externals so that it points to a single location.
That way we can automatically push out new versions to all developers and projects. For projects on release branches, rather than HEAD, we can specify the revision of svn:externals reference if we want to leave nuget alone.
We have a lot of projects, so it also means not duplicating nuget.exe multiple times in the repo.
We have the nuget.config file in the folder, as it has the references to our internal Nuget server, using the Package Sources area:
https://docs.nuget.org/consume/nuget-config-settings
Apart from this reason, you should let Visual Studio handle the downloading of packages.
Related
I recently successfully switched all of our projects over to automatic NuGet restore. To do this I followed this guide. Everything worked great, I was able to delete my /packages folder and restore to my heart's content.
One of the steps in that guide says to edit your .csproj file and remove the EnsureNuGetPackageBuildImports related element.
The problem I am having now is that, after going in and downgrading one of my projects libraries, NuGet seems to have automatically added the EnsureNuGetPackageBuildImports related element back into my .csproj file.
Is there some other setting I should be changing to prevent NuGet from doing this? I would rather not have to edit my .csproj file every time I make a NuGet related change.
Is there some other setting I should be changing to prevent NuGet from doing this?
I`m afraid the answer is not if you going in and downgrading one of your projects libraries.
The target "EnsureNuGetPackageBuildImports" is used to ensures that the imported .props or .targets files are indeed imported in the old way "Enable Package Restore". NuGet has supported NuGet MSBuild support since NuGet 2.5.
Since Nuget 2.7+, Microsoft has dropped support for the 'Enable NuGet Package Restore' in VS2015 and you need to do some manual changes to either migrate old solutions or add the feature to new solutions. Nuget Automatic Package Restore has changed in Nuget 2.7+. Unfortunately, it looks like a non-backward compatible change. We have some developers on 2.7 and before who will now need to upgrade to 2.7+. In this case, NuGet will automatically added the EnsureNuGetPackageBuildImports related element back into your .csproj file when you going in and downgrading one of your projects libraries.
To resolve this, we advice that do not mix 'old' and new methods for automatic package restoration(Remove that files when you use automatic package restoration).
Besides, if going in and downgrading one of your projects libraries is unavoidable, there is a PS script can help you remove it more convenient:
DisableNuGetPackageRestore.ps1
Our VS2013 solutions contain a solution folder called .nuget, containing the files NuGet.config, NuGet.exe, NuGet.targets. What is the significance of this folder and what uses the files? Is it related to the "enable package restore" feature?
If I install or update a package (via the "Manage NuGet Packages" UI or package manager console), does this involve running the above NuGet.exe, or something else? VS is telling me that the NuGet Package Manager is up to date (via the Extensions and Updates dialog), however the above NuGet.exe is quite old. I've also found a very old NuGet.exe file in C:\Program Files (x86)\NuGet\. What uses the latter, and what are the implications of these exes being out of date?
The reason I ask is that we've been having problems with a couple of solutions over recent weeks. We can't update NuGet packages - the operation fails with the message "Error: An item with the same key has already been added". I'm trying to track down the cause, and wondering if these out of date NuGet.exe files might have something to do with it.
As far as I remember this folder is useless now with the latest nuget extension to Visual Studio. It was used before and was nothing but pain in the ass. I am not 100% sure about 2013, but in 2015 all works fine without it, so my suggestion is to update to the latest available nuget extension version and try to delete the folder, most likely everything will work.
Now packages go to current user folder, and use the config from %AppData%\NuGet\NuGet.config. For NuGet 2.6 or earlier, this setting was available in a project-specific .nuget\nuget.config file.
You can read more about it here.
So nuget is gradually getting better and easy to use without too much thinking of all this "magic" folders and stuff.
We have a solution which contains several projects. Some projects have NuGet packages installed, for example Json.NET. The whole solution is checked in to TFS Version Control, without the packages folder. We have set up Automatic Package Restore according to the "Nuget 2.7+ method" as described in the Nuget documentation (actually we didn't set up that much since all this is enabled by default).
When we build this solution on another computer, all packages are getting restored.
When we build this solution on our TFS 2013 Build server, all packages are also getting restored.
Now here comes the problem:
When we create a build on our TFS 2013 Build Server which should build only one of the projects in the solution (so targeting the .csproj file instead of the .sln file) the nuget packages are NOT getting restored!
Can anyone tell me why this is happening, or tell me if this is by design? I really don't want to build the whole solution, since it is a release build for only a single small project, but i do want the packages getting restored automaticly...
I believe the Automatic Package Restore hooks into the Build Solution event. Since there's no solution, it's not triggering the restore.
To build a single project, you may need to create a new solution that references just that project.
I am trying to move my solution to utilize NuGet Package Restore so that I can keep the packages folder out of source control. I have some confusion as to how to properly implement it however.
I currently have the packages folder in TFS, should I delete it before committing the changes for NuGet Package Restore?
Do I need to commit the .nuget folder to source control? This article is telling me to remove .NuGet.exe and NuGet.targets as well.
Will using NuGet Package Restore break build in TFS? (say for gated check-ins)
Yes.
The better option is to use the Package Restore Migration script. I've used it several times and it works beautifully. It will remove NuGet.exe, NuGet.targets, and also (very importantly) clean up your project files to remove references to the NuGet.targets file. If you just delete NuGet.targets, it will break your builds.
NuGet package restore shouldn't break any builds if you follow the steps outlined in the article you linked very closely. Of course, your build server will need access to the internet so it can get to nuget.org. If your build server is locked down and has no internet access, package restore will definitely not work.
Make sure that you close down Visual Studio before running the package restore migration script... I've found that if you run the script with the solution open, it won't work properly.
If you're using Git, add the packages folder to your .gitignore.
If you're using TFVC, make sure that your NuGet.config file has the disableSourceControlIntegration key set to true.
From Visual Studio 2013 update 3 Nuget package restore is the default and does not need enabled.
If you delete the /packages folder and check in it should just populate automatically with no additional work required.
Yes: Remove nuget.targets and .nuget folder.
When other developers get the vs.net 2013 solution from TFS, Nuget doesn't seem to work as expected and many of the individual projects in the solution do not have the required dll's downloaded (although they are defined in the packages.config file).
If I go to view the installed packages, it shows up as they are installed and the correct projects are selected.
I went into console and ran:
Update-Package -Reinstall
After doing this, my packages.config file was truncated for whatever reason and 80% of my packages were removed from the config file!
What should I be looking into as it is either I have setup the solution incorrectly or nuget just isn't reliable.
Thoughts?
First of all make sure that NuGet Packages Restore is turned ON.
This forces to restore missing binaries directly from NuGet server. You can right click on Solution and enable this option as follow:
Make sure that .nuget folder that contains nuget.exe is created under your Solution.
You'll want to make sure that you have automatic package restore turned on in VS 2013. You can do this in the options.
Then, when you build, VS should grab the packages for you. If you want to manually restore the packages or do it from powershell, you'll want to use the command nuget.exe restore in the folder your solution lives in.
If you're using custom package sources, you'll want to make sure you specified them in your nuget.config file.