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.
Related
During the installation (or restore) of a Nuget package, it also checkout web.config(s) of other projects and I manually have to go one by one to undo all of this unnecessary checkouts.
How to avoid this?
Seems you are using a Server Workspace (a workspace configured for Server mode)
As a workaround you could change to a Local Workspace. In a local workspace files are not marked as read only and can be edited outside of Visual Studio.
I'm training 5 people on using Visual Studio. They've mapped their drives and have "downloaded" the solution from TFS which contains 10 projects. All located at the same depth in TFS folder structure. When the new folks download the solution there's one project that doesn't get the NUGET references even though the Package folder (created by NUGET) is at the same depth of the other 10 projects when viewed in TFS.
We know how to add these manually but is there a way to automatically have VS do it? Why would only one project lose it's reference with the Package Folder right there?
It seems you are still using MSBuild-Integrated package restore approach. If NuGet recognizes that the MSBuild-Integrated package restore approach is enabled for the solution, Automatic Package Restore is skipped.
You need to migrating MSBuild-Integrated solutions to use Automatic Package Restore, then the packages will be restored automatically.
In addition, you need to update you NuGet manager to the latest version in VS Tools--Extensions and Updates. And make sure Visual Studio is configured to 'Allow NuGet to download missing packages' and 'Automatically check for missing packages during build in Visual Studio' in VS Tools--Options--NuGet Package Mnager--General.
To Fix:
Unload all projects first, then right click and select edit project.
Find this line:
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
Comment it out.
Reload all the projects and compile.
This applies to Nuget api version 2.
Note you may configure all projects for Nuget at the solution level.
The package manager for the solution presents a set of check boxes for every project along with the buttons (Install or Uninstall).
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.
So I downloaded Twitterizer from http://www.twitterizer.net/downloads/
I try to open it in Visual Studio and get all these nuget errors:
The imported project "C:\Twitterizer\.nuget\nuget.targets" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file
exists on disk.
What is going on. How do I deal with this?
Install Nuget.
Right click on the solution and select "Enable NuGet
Package Restore". In Visual Studio 2013 and later, select "Restore NuGet Packages" instead.
Click Ok on the warning.
Close and re-open the solution.
Should now be hunky-dory.
An alternative is to edit the .csproj file with a texteditor and remove or comment out the segment.
This error normally happens when you are trying to open a .csproj directly, not through the solution file, and the .csproj imports the Nuget targets like this:
<Import Project="$(SolutionDir)\.nuget\NuGet.targets" />
In order to solve it, you can either open the .sln and not the .csproj directly...or remove the import line above.
Notice that the mentioned error will only happen when you are using solution wise package restore, which isn't even recommended anymore.
Just ran into the same problem, but in my case the issue was a space in the folder name:
Nuget was telling me it couldn't find "C:\git\My Path" but I was able to navigate to "C:\git\My%20Path". Removing the space in the foldername "fixed" the issue.
I know I'm late to the party but here is a really good tutorial on how to fix this issue. I used this to fix my project.
Close down Visual Studio If the solution you are trying to migrate is
open in Visual Studio, then changes may be lost. Visual Studio may
overwrite/ignore your changes in some cases and the NuGet extension
will also try to re-enable Package Restore when it sees some projects
in the solution are missing it.
If you are using TFS Remove the NuGet.exe and NuGet.targets files from
the solution's .nuget folder. Make sure the files themselves are also
removed from the solution workspace. Retain the NuGet.Config file to
continue to bypass adding packages to source control. Edit each
project file (e.g., .csproj, .vbproj) in the solution and remove any
references to the NuGet.targets file. Open the project file(s) in the
editor of your choice and remove the following settings:
true ... ...
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download
them. For more information, see
http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is
{0}.
If you are not
using TFS Remove the .nuget folder from your solution. Make sure the
folder itself is also removed from the solution workspace. Edit each
project file (e.g., .csproj, .vbproj) in the solution and remove any
references to the NuGet.targets file. Open the project file(s) in the
editor of your choice and remove the following settings:
true ... ...
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download
them. For more information, see
http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is
{0}.
Migration Script
Many users have requested a migration tool to disable the
MSBuild-based package restore and convert to Automatic Package
Restore. The NuGet team has decided not to provide a supported tool
for this because of the high probability of edge cases that would be
unhandled. However, Owen Johnson has authored a PowerShell script that
can work in many cases. It's available on GitHub and can be used at
your own risk. In other words, be sure to commit to source control
before running it, just in case it doesn't work in your scenario.
Nuget.target Fix
When i get the nuget.targets not found error i use the package manager to uninstall-package one of the packages in the project and then reinstall it using install-package. It seems like it regenerates the nugets.target file then.
Easiest solution when you get this error in order to restore the missing NuGet.targets in Visual Studio Solution Explorer is to:
Right click on the solution file
From the context menu click "Enable Nuget Package Restore..." option
this will download the missing files in the ".nuget" folder :)
The above assumes you already have Nuget installed - if not follow the accepted answer above!
UPDATE:
Please note for Visual Studio versions beyond 2013 the option is called "Restore NuGet Packages"
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.