I have existing .NET solution that is in TFVC source control. When I added a nuget package, the packages folder and all it's contents were added to the project in source control. In the future, how can I ensure that NuGet packages will not be added?
Add a “.nuget” folder to the folder where the .sln file resides. Open up Source Control Explorer in Visual Studio, browse to that folder, right-click and choose New Folder.
Inside this folder, add a file named NuGet.Config. To do this you’ll need to open up File Explorer and browse to the .nuget folder you just created, and create the file. Add this to the file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
</configuration>
Add a .tfignore file to the folder where the .sln file resides. You need to do this in File Explorer as well. It’s a little tricky to add a file with only an extension like that. You have to name it with a trailing dot like “.tfignore.”.
Finally, you need to add the .tfignore and the NuGet.Config files to TFVC. To do this, open up Source Control Explorer in Visual Studio, browse to the proper locations, right-click and choose Add items to folder.
Source: https://learn.microsoft.com/en-us/nuget/consume-packages/packages-and-source-control
Note: The best practice is to not store the actual packages in source control. Only the packages.config file should be checked in. The packages.config file will allow any fellow developers who download the solution to restore the packages from the package source.
We have the following project structure in a solution:
.\Project2
.\Project1
Project2 is dependent on Project1. Project1 is shared across multiple projects. I added the nuget packages (Roslyn for example) for Project1 when it was part of this solution. The problem we are having if either we try to compile Project1 by itself or compile it when its in an entirely another app it fails:
This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ../../Project2/packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props.
If i open the project file in a text editor it has the following statments in the project file:
<Import Project="..\..\Project2\packages\Microsoft.Net.Compilers.1.2.2\build\Microsoft.Net.Compilers.props" Condition="Exists('..\..\Secured Account Access\Member\packages\Microsoft.Net.Compilers.1.2.2\build\Microsoft.Net.Compilers.props')" />
If of course removed all the nuget references and then just opened the individual project and added the nuget references. Which fixed when i was trying to compile the project by itself and broke it when it was part of the solution because VS will no longer restore the packages for Project1 while its in the solution.
I'm not sure why VS/Nuget works this way. Why not always have a package folder for each project? Disk Space savings (which would be absolutely nothing)? You should never have references that look like the following:
../../Project2/Packages/MyNugetDepedency.dll
Is there any way to get around this and have everything just work.
The packages folder is determined by the solution the project is contained in by default. You can override the default packages directory by specifying the repositoryPath in a NuGet.Config file.
<configuration>
<config>
<add key="repositoryPath" value="../MyPackages" />
</config>
</configuration>
To have multiple solutions all share the same packages directory you can create a NuGet.Config file, with a repositoryPath setting, in a directory that is a parent to all the solutions. NuGet will then work its way up each directory until it finds a NuGet.Config file and then use the repositoryPath defined there. This repositoryPath is relative to the NuGet.Config file itself, unless you have specified a full path. A relative path is probably what you want so other developers do not need to check out the source code to the same directory.
I have a solution in Visual Studio 2015 with about 40 projects in it. Some of these projects have some NuGet packages referenced.
Due to a combination of our branching strategy (where each project folder is branched individually) and our security requirements (that the NuGet binaries are actually checked into TFS) I would like the NuGet packages for each Project to be installed into each Project's folder, not in the solution's folder. Space usage is not a concern here.
I've looked at:
https://docs.nuget.org/consume/nuget-config-file
https://docs.nuget.org/Release-Notes/NuGet-2.1#Specify-packages-Folder-Location
And they've helped my understanding of how the config files work... but I can't seem to get it to do what I want.
I've tried this in my config file:
<configuration>
<config>
<add key="repositoryPath" value="$(ProjectDir)\Nuget\" />
</config>
</configuration>
But it creates a folder in the solution folder actually called '$(ProjectDir)'.
And I can't hardcode the path to the project folders (i.e. 'C:\myteam\teampackages' in the NuGet docs) as pretty much everyone in the team have different paths to their local workspaces!
How can I do this?
Firstly, you should not check in NuGet packages into TFS Version Control. As one of the advantages of using NuGet is that you can use it to avoid checking in binaries to your version control system.
Instead, you need to restore NuGet packages during TFS build process and the required packages will be downloaded. In VS2015, you need to follow steps in this blog: https://docs.nuget.org/consume/package-restore/team-build).
Some key steps are (assume you're working with XAML build):
Add following items to the solution. (Content of the nuget.config and .tfignore file can be found here)
Add one build.proj file under the root path of the solution folder. (Content of the build.proj file can be found here)
Create one folder named tools under the root path of the solution folder. Create NuGet sub-folder under tools folder, download and save nuget.exe under tools\NuGet path.
Check in nuget.config, .tfignore, build.proj and tools\NuGet\nuget.exe into TFS version control.
Modify the build definition to choose to build the build.proj file.
Then you will have NuGet packages restored successfully during the TFS build process.
The Nuget docs mentions specifying package folder location is to have many different solutions share the same package. This is an opposite scenario as your. Repository path setting only allows you to install the NuGet packages in the specified folder (like C:\teampackages ) or for relative path (like ../Nuget).
To make installing package in different repositoryPath, you can try:
<configuration>
<config>
<add key="repositoryPath" value="../Nuget" />
</config>
</configuration>
Check case: Is it possible to change the location of packages for NuGet?
I'm trying to get TFS (2013) to ignore my packages folder. I passionately don't want it source controlled as I'm using NuGet and it's great!
I've tried cloaking (doesn't seem to work), I've tried adding .tfignore files - nothing is ignored. Why don't the TFS team just add an option to permanently ignore a folder or file like lots of the Subversion clients do?!
Here's the deal: We have to tell both NuGet and TFS to ignore the packages, because NuGet is trying to do source-control related stuff that it absolutely shouldn't be doing (bad form, Microsoft!). So you have to do two things.
First, add a file named .tfignore to the solution folder (note the lack of s after the tf). Its contents should be as follows:
\packages
That tells TFS to ignore your packages folder. Now, you would think that this would also ignore the repositories.config file. But it won't. Why? Who knows, the ways of Microsoft are strange and mysterious. Actually, I think it's part of the NuGet stuff I outline below, but if that ever gets fixed in the future and you want to keep the repositories.config file instead of letting VS regenerate it, you should be able to use this:
\packages
!\packages\repositories.config
OK, so now thanks to our .tfignore file, TFS is ignoring your packages. Everything is fine, right? WRONG, because NuGet is mucking around with your source control and adding the packages to your pending changes. So now let's tell NuGet to cut it out already.
Create a folder called .nuget in the root of your solution folder.1 Now, create a file called NuGet.config, and put it in this new folder2. Its contents should look like this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
</configuration>
And now your packages should stay out of source control. Just remember to add the NuGet.config and .tfignore files to source control so they never get lost.
EDIT: If you're having issues, you may want to delete your packages folder, check in that change, and then go through the steps above.
ALSO EDIT: It looks like this won't happen with newer versions of Nuget. So maybe if you switch to VS/TFS 2017 this issue will clear up without jumping through the above hoops.
1. Add the folder using Source Control Explorer; right-click the solution->Add folder->.nuget
2. When I figured this out using VS 2013, I found the NuGet.config had to go in the .nuget folder. Even if you already have a NuGet.config file in the root of your solution folder (because, say, your company has an internal nuget feed). However, some in the comments have indicated that it works fine in the solution root in VS 2015. Personally, I switched to using TFS in git mode, so I can't test. Additionally, if you do have a custom feed, ensure that you have both the custom feed and nuget.org as keys in the Nuget.config file, or sometimes TFS will randomly decide it can't restore the packages.
An alternative solution to the above is the following.
Add the packages folder to TFS (without any files or sub-folders)
Right Click the Packages Folder
Left Click Advanced
Click Cloak
It is worth noting that this solution would need to be applied per TFS workspace. It has worked far more reliably for me rather than using the .tfignore file.
You can read more about this approach in the blog article Prevent TFS from adding installed NuGet packages to source control.
for people reporting that the .tfignore option wasn't working with the nuget.config setting it might be of interest - these steps finally worked for me:
Delete everything in my packages folder
Make sure TFS doesn't have any changes around that folder pending
Close VS
Re-open VS, and reload solution - using Nuget restore to re-populate
packages Note no changes are pending for TFS source control
Add a nuget.config file in a .nuget folder in your solution.
Add the following to the nuget.config file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
</configuration>
The disableSourceControlIntegration is what makes the trick for TFS Version Control.
You need to be using local workspaces for .tfignore to work. The .tfignore file must be in the folder that contains the files or folders you want to ignore.
So if your solution structure looks like this:
\Project
\Packages
\OtherStuff
foo.cs
You'd put your .tfignore file in \Project:
\Project
\Packages
\OtherStuff
foo.cs
.tfignore
The contents of the .tfignore in your case would be:
\packages
Here's some documentation for you: http://msdn.microsoft.com/library/vstudio/ms245454(v=vs.110).aspx#tfignore
You can permanently set this once-off in your AppData\Roaming for all solutions (old & new)!
In your %AppData%\NuGet\NuGet.Config file, add the following just before the </configuration> XML tag...
<config>
<add key="repositoryPath" value="C:\NuGetPackages" />
</config>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
...you can specify any path you want - the important thing is putting it OUTSIDE your TFS workspace!
Now you never have to worry about that stuff again. Your solution folder will not contain any packages anymore; all solutions will default to using your custom packages location instead.
NOTE - This works is on a per-user basis.
Set your solution to restore on build, the package folder and packages file will be checked in but the packages won't.
If you are using Git with TFS you need to add a ".gitignore" file. You can do this in "team project | Settings | 'add ignore file'". Then open the file and uncomment the built in ignore statement for Nuget Packages.
If you are using TFVC and you have Local Workspaces configured you can use the ".tfignore" file that honours an identical format to the Git file. I think you need "packages/".
This didn't work for me quite on visual studio online and VS2013.
Right Click Solution > Enable NuGet Package Restore. This will add the Nuget.config file to solution
Add the .tfignore. I normally do this by adding a text file to the solution root, letting it detect that and then exclude by clicking 'detected add' > right click ignore.
Add the packages to .tfignore and tell it to include repositories.config
From the other comments it seems your milage may vary at this point. This is what I do:
Check everything in, including any packages.
Delete all packages in your solution and then check in this change (this will remove the packages from TFS)
Open the solution and build which will add the packages to the project but TFS will not pick them up.
The solution that worked for me was to create both a .tfignore and the following setting in the Nuget.Config:
<configuration>
...
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
...
</configuration>
My .tfignore contains this line:
\packages
[I'm using Visual Studio 2015 Update 2]
This is not ideal, and is currently logged as an open issue on github/nuget:
Make it easier to omit packages from TFVC #493
Terje's answer doesn't work all the time for me, sometimes it will work for a while, but then it will pend a load of "adds" for me all over again.
The only way I have found to solve this permanently is to Cloak the packages folder in my Workspace.
For example:
Type Server Local
============================================
Active $/Work/Main C:\Code\Main
Cloaked $/Work/Main/Packages
I had the same issue. /packages should work but didn't for me. packages*.* did work.
I placed a nuget.config file in my project root folder that specifies where all NuGet packages should go for all my solutions.
Here is the file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="D:\Projects\Development\NuGet Packages" />
</config>
</configuration>
I have also enabled NuGet Package Restore on all my solutions.
When I first set this up, the nuget.config file was being ignored--all NuGet packages were being placed in a "packages" folder in the solution folder. I tried deleting this folder numerous times, but invariably, NuGet would recreate it and fill it with packages.
After much trial and error, I stumbled upon the <PackagesDir> element in "NuGet.targets" and noticed that commenting it out finally allowed the packages to be placed in the correct folder in my project root.
Here's the relevant line from NuGet.targets
<PackagesDir>$([System.IO.Path]::Combine($(SolutionDir), "packages"))</PackagesDir>
My question is simply whether commenting out the PackagesDir element in the NuGet.targets file is the intended method to get my nuget.config file to be followed or if I'm missing a more obvious solution.
There are two things in play in your question:
Where does NuGet store packages?
NuGet package restore for the open project(s) / solution
Regarding the first: setting the repositoryPath key in your nuget.config file is the correct approach to instruct NuGet to extract packages in a different folder from the default. This setting is used whenever a developer adds a package refernce to your project.
For NuGet package restore, thissetting is overridden by the setting you found in NuGet.targets. This setting is used when restoring packages upon build of a solution.
If you want to use package restore and a custom path, you indeed have to specify both. The first one for your devs, the second one for package restore.