I am attempting to migrate to nuget's new Automatic Package Restore. Whilst it works fine on my own machine (packages are restored), builds performed as a TFS Build on the build server do not build, complaining that they cannot find the various dlls (that should have been downloaded as part of the restore).
I have created a nuget.config in my solution folder, as specified here:
http://blog.davidebbo.com/2014/01/the-right-way-to-restore-nuget-packages.html
I have also tried putting this nuget.config file next to the nuget.exe file in TFS, in the hope that it would be used, but to no avail.
The nuget reference here:
http://docs.nuget.org/docs/reference/nuget-config-file
states that the nuget.config in my solution folder should be picked up. But it appears that it isn't.
I'm at the end of my tether. According to nuget, the Package Restore feature is designed specifically so that packages don't need to be checked in. However, there's scant information about how to get TFS to actually restore the packages, and what I've found does not work.
Any help would be gratefully received.
My nuget.config looks like this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
<packageSources>
<add key="nuget.org" value="https://www.nuget.org/api/v2/" />
<add key="ads" value="<address to local repository>" />
</packageSources>
</configuration>
As it so often turns out, the answer is the answer to a question I didn't actually ask:
"How does TFS even know how to call nuget?"
After sitting and thinking about this for a while (and as #Matt Ward correctly points out) it occurred to me that the TFS Build has no way of knowing nuget is even involved, since the new "Automatic" package restore removes the need for it to be part of the build itself.
This question has actually been asked here:
How does TFS know about nuget?
Although the accepted answer is NOT actually the correct one. Scroll down to probackpacker's answer, which is essentially that:
"If you are using automatic package restore, you must have a build process that calls it before building your solution"
This is actually well documented at nuget:
http://docs.nuget.org/docs/reference/package-restore-with-team-build
However, I had disregarded it since a) the entire point of Automatic Package Restore is to move away from an MSBuild based process (although I do now understand why this is different), and b) it seemed more complicated than I needed. It's not. That said, a clarifying statement such as "If you are using Automatic Package Restore with TFS Team Build, you MUST create a an MSBuild project in order to call Package Restore" would have been helpful. It's obvious once you understand what's happening - confusing when you don't. But we live and learn.
depending on the version of visual studio, it should just be a matter of right clicking on the solution and selecting Enable NuGet Package restore. this will create a Nuget folder that contains, NuGet.exe, a NuGet.Targets file and NuGet.config.
you can update the targets file with a local NuGet Feed if you have one.
to test locally, delete the contents of your packages folder, and ReBuild the solution, this will download the files from NuGet and your solution should build correctly. check in the NuGet folder and files to source control, your packages should not be added to source control.
your TFS build should now be able to restore the packages
Now if this is how you are set up and it still doesn't work on TFS, log onto the build server with the build account and load the solution locally, make sure the package restore works as the build account on the build machine, you may have a firewall / proxy issue, where the build server / build account can't access the Nuget.org internet site
Related
I am finding it a common issue where when I download a .NET repo from Github, the solution has missing references. See an example below. When using Nuget Package Manager, it says the packages are installed already. The packages folder is missing.
I tried using 'Update-Package -reinstall' and got a bunch of lines with 'No package updates are available from the current package source for project 'project name'.... That's probably due to the missing package files.
I can fix each reference manually but it's a time consuming process. Is there a way to force fix all these references in all the projects in one swoop using a command or a tool that 'cleverly' knows what to do? I am using Visual Studio 2019 16.3 preview 1
In VS2019, those .net core projects or .net standard projects use PackageReference instead of packages.config format to manage nuget packages. And in this way, the content in xx.csproj looks similar to this:
<ItemGroup>
<PackageReference Include="FluentValidation" Version="8.1.3" />
<PackageReference Include="MediatR" Version="6.0.0" />
<PackageReference Include="AutoMapper" Version="8.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.2.3" />
<PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="2.2.0" />
</ItemGroup>
Every time you download a project which uses packageReference format, you only get the xx.csproj and related source files but without nuget packages. So when you open and load the solution or project in VS IDE, it will display the nuget packages name in solution explorer but with yellow warning triangle since now VS can't find those packages locally.
Is there a way to force fix all these references in all the projects
in one swoop using a command or a tool that 'cleverly' knows what to
do?
Just like what zivkan said in his answer, NuGet is normally configured to restore packages automatically if you've enabled those two options. Every time when we load the soultion in IDE, it will automatically restore the packages for us. Not sure the reason why it seems not to work in your machine, but you can check and try:
1.Go Nuget Package Manager=>Package Sources, make sure you've set https://api.nuget.org/v3/index.json as one the Available Package sources.
2.Right-click the solution in Solution Explorer, choose the Restore Nuget Packages to restore packages for whole solution.
3.Or you can Unload and reload the project to check if it helps.
4.By default, the packages are stored at C:\Users\xxx\.nuget\packages folder, you can check if those folders exists there.
(I delate all packages in that folder, so it's clear when I open the git solution in VS, the nuget is installing those necessary packages automatically, I'm not sure if there's any possibility that cause too many packages are being installed,so it will take some time? I check and find, to restore necessary packages for NorthWind solution, it require packages for over 370 MB)
I tried using 'Update-Package -reinstall' and got a bunch of lines
with 'No package updates are available from the current package source
for project 'project name'.... That's probably due to the missing
package files.
And for the reason why Update-Package -reinstall not work well in the project, maybe it's a similar issue like nuget issue #4103, for the packagereference in xx.csproj, several commands for now are not supported.
And after my check in my machine, the command obviously do not work for a PackageReference-format .net standard project. When I've installed related packages successfully, I run this command but only get No package updates are available from the current package source for project xxx, then I delete the installed packages, clean the cache and run the command again, I still get same message!
So I think this command can't recognize PackageRefernece format in .csproj, no matter whether I install related packages or not, it will always throw message No package updates are available ...
NuGet is normally configured to restore packages automatically. See the options page. The second Package Restore option, "Automatically check for missing packages during build in Visual Studio" is enabled by default on clean installs.
Here's a little video I recorded of what happens on my machine when I open the solution. Keep an eye out on the status bar at the bottom left of the window.
If your installation of Visual Studio does not behave in the same way with the automatic restore option enabled, then there is some other issue on your machine, but we don't have enough information from your question, as of the time I wrote this.
I have a few projects using numerous NuGet packages and these projects are source controlled on TFS. Whenever the packages are restored, they are automatically readded to source control.
I am using Visual Studio 2013 Update 3 and TFS 2013 with local workspaces and my NuGet version is 2.8.50313.46.
I am apparently not the only one to have this issue. Quite an amount of people have been asking this on StackOverflow but none of them were able to solve this issue or at least not with new implementation of package restore in NuGet. I tried the .tfignore in solution folder with '/packages' exclusion but it did not work either. So I am now asking for help here because sooner or later, someone is gonna checkin those files!
Thanks.
Note: There is about 20 users using this TFS, so applying an individual fix on each machine is not something I am looking into.
You can add to your solution new folder called ".nuget", under the folder put file called "NuGet.config", inside the file add the nuget configuration:
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
</configuration>
For more information: http://docs.nuget.org/docs/reference/package-restore
Right click on the solution folder -> enable nuget package restore on build.
That will create the required configuration, and also enable other team members to build the project automatically.
then you should commit the project. make sure to delete all packages. and then if possible try a new checkout on each machine.
I have a solution with 6 R&D projects in it. Recently we upgraded to Visual Studio 2013 and after upgrading the solution I added a 7th project (ASP.net MVC) which added a packages folder to my solution folder.
I recently added my solution and projects to our production share which is shared across 3 other developers. We have a libraries subfolder that our production solution references. Discussing my newly added solution and project folders to our production environment with our build developer, he would like to see the packages folder moved as a subfolder of the Libraries subfolder and all the team reference the single packages folder at that location. We do not use Team Foundation.
Since I did not tell nugget where to create the packages (they were just placed in the solution folder) is there a way to tell it where to look for the packages after I move the folder to its new location? How will the other developers configure their Visual Studio instance to look at the shared folder instead of their local machine? Assuming, once they build the solution locally it will also add a local packages folder and we don't want that.
Seems like this is pretty straight forward. In fact, NuGet site says you can share packages folder but it says you have to modify nuget.config and I don't have that in my solution. Any thoughts/suggestions are appreciated.
Nuget, in and of itself, is a package management repository. It's entire purpose is to allow you to centrally pull down packages (libraries, configurations, whatever) that you need to a place locally on your system (whether it's dev, production, whatever) without having to actually commit those libraries to your source control. Instead, any developer will just be committing a file that says the equivalent of, "Get me a package by this ID (name) and version."
This process creates a file called packages.config at the top level of every project within your solution. The file would look something like this:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="EntityFramework" version="6.1.1" targetFramework="net45" />
<package id="jQuery" version="2.1.1" targetFramework="net45" />
</packages>
The files themselves are placed in the projects where they need to be (in the case of projects like jQuery) or, library binaries are stored at the top-level of your solution in a folder called packages and should not be checked into source control.
You can also enable "auto-restore" packages for Nuget so that when anybody checks out your project, they will automatically get the libraries and things they need in order for your project to run/build correctly.
This means that everybody gets what they need, you do not need to manage your own "library repository" (please...no shared folders!), and, at any point, you can look at the packages.conf folder to see what your project depends on.
Here are some more links on how to enable and work with Nuget for development and build systems. There are scores of other resources on the web as well.
Introduction to Nuget
Using NuGet Without Committing Packages
Package Restore
I have a Visual Studio project which I have committed to VisualSVN (via the VisualSVN => Commit menu in Visual Studio). I have added a number of libraries to this project via NuGet.
My colleague has downloaded the project I have uploaded to SVN (via VisualSVN => Get solution from Subversion...) and has found that these libraries are missing, and he is having to re-download them.
A few questions:
Is this by design? Or have I not committed my Solution properly? Or has my colleague not download the solution to his machine properly?
If this is by design, what is the correct way to re-add references to a solution downloaded from an SVN server? I am worried that I may have added a reference and worked with it, and that it may have been updated since so whenever my colleague re-adds the same reference via NuGet he will get a more up to date version that will be different, and this will break my program. Is this a valid concern?
Yes, this is by design. The whole concept of using Nuget is that you will not have to keep libraries in your version control system.
You need to Right Click on your solution in Visual Studio and select Enable NuGet Package Restore.
This will configure the solution to restore the NuGet packages (if any missing, or in case of none) whenever you'll do a build. Also, all the libraries that you've added for a particular project will have an entry in the packages.config created in the project's source drectory; for eg:
<packages>
<package id="jQuery" version="1.8.3" />
</packages>
This way NuGet makes sure everybody gets the same version.
Just enable "Nuget package restore" in your solution and packages will be automatically downloaded during the build:
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-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.