I recently upgraded an old ASP.Net MVC3 project that was storing all our COTS (commercial off-the-shelf) .DLL files in source control to use NuGet Restore Packages instead.
Now whenever someone gets the source afresh from TFS (Team Foundation Server), the references I updated to NuGet Packages all have the warning icon on them. Neither building nor cleaning and rebuilding fix the references.
If I click any NuGet reference in a project, the references all appear to update. The warning icons disappear and the references seem to be fine. The project builds without sissue.
This has to be done for each project in the solution, though once done once it is fine and doesn't reoccur. But this is slowing down new employees and is cumbersome.
Does anyone know of something I might have missed?
The .ddl files are for packages like MVC, StructureMap, Log4Net ect
I have searched (via Google) and the only related question is one showing NuGet packages having a different icon.
You can use the Restore Nuget Packages option from the Solution Explorer by right clicking on the solution:
You can also configure Nuget Restore to run on build from the Nuget Manager Settings windows:
Related
I am wondering if anyone is aware of how to properly include an Nuget package in my application. Installing it - adds the references automatically in Solution Explorer. In addition it create/display a file called package.config - and it looks like it wants to be added in my project. It is shown in Solution Explorer but appears in my root folder with a little + sign next to it - and allows me to Check In Pending Changes / add it. Am I supposed to add it to my project?
I basically don't want to screw up anything.
Yes the packages.config file is required. This file holds the packages you reference and the versions youre using. NuGet uses this file to restore your packages in a TFS build of on the machine of another developer.
Here is some more information on NuGet dependency resolution
Note that you should not checkin the packages folder in your solution folder. NuGet will restore packages to this folder using the packages.config file
UPDATE: the <PackageReference> format was introduced a while back. It can be used with both the old and new .csproj formats. One of the benifits is that the paths to the packages are no longer in your project file so you will get a lot less updates/merge conflicts when updating NuGet packages. See this page for more information: https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files
Yes, it's usually checked in as part of your solution. Source control and all that.
I have a small solution containing three Visual Studio projects. I'm working in Visual Studio 2015 using TFS 2015.
I have implemented a gated check in, but for some reason the solution will not build on the TFS server. I'm referencing only 1 nuget package - Entity Framework. I am not checking my package folder into TFS, but my packages.config files are being included.
I have previously set up a different project on the same server using the same build definition and it works fine.
In order to restore packages prior to build, you will need to run the following command as part of your build process.
nuget.exe restore path\to\solution.sln
One way to do that is to add another project that is responsible for building your solutions and making sure that the packages get restored prior to your solutions being built.
Following write-up walks you through getting that set up: nuget docs
I managed to get it working, but I tripped into the fix and don't know what exactly solved the problem. This is the first time I've really had to handle TFS builds.
I know I only had one build definition defined and it was intended for a different solution - of which this code was also a part. I think when I was checking in this solution it was actually trying to build the other.
Apparently, I can't have my nuget packages set up different ways for code that is in two different solutions. Anyway, that's my best guess.
In TFS 2015 I have a Team Project with multiple solutions. The only way i can get the individual solutions to build correctly is to have a mapping for the Entire Team Project, so if i've got 5 builds set up, each of the build directories contains a copy of everything in the team project, which takes up a fair chunk of disk space
If i supply a mapping for just the solution i want, then it fails.
In this instance the solution is very simple. It's just a solution that contains the domain model, with Entity Framework as the only external dependency. The build fails because it can't find the EF assemblies. The Ef packages are being retrieved from Nuget, but they are't being copied into the Bin folder (The bin folder is empty).
Any ideas? Please let me know if you need more info
Sounds like a NuGet issue more than TFS. Is your packages folder checked into source control? If so, then the associated binaries have probably been excluded by TFS and so it think it has them but actually doesn't. Delete the packages folder from TFS and ensure the build definition is set to clean (or manually delete the sources directory on the agent(s)) and then see my answer here for a good setup (Note the link to the NuGet website, worth a read) :
Visual Studio 2015 loses Nuget packages on new installations
We have 1 Team Project with multiple solutions too so it's definitely not a limitation, just something muddled somewhere.
I see that there are new versions of ASP.NET MVC and Web API
If a solution references these NuGet packages, will it automatically update them to these newer versions with options set thus:
?
No, you still need to go to the package manager, and check the updates section.
The setting here allow the project, when built for the first time, to go to nuget and fetch the dependant assemblies. For example, if a colleague was to get the solution for the repo for the first time, when they build, all the assemblies will be downloaded.
NOTE: Be careful when updating, I usually tend to do it in small bunches at a time and check the solution still runs / builds after each update.
No. NuGet does not automatically upgrade packages. If you want to update a package, you'll need to do it manually.
However, NuGet will download missing referenced packages in order to allow a project to build correctly, which is what those options reference. There's more information on Package Restore over at NuGet.org.
Our projects in TFS are organized like this:
$\DefaultCollection\ProjectName\Source <-- source code goes here
$\DefaultCollection\ProjectName\SharedAssemblies <-- 3rd party binaries go here
Now that NuGet is on the scene, is there any reason to change our approach and use NuGet's packages folder for dlls that come from NuGet-aware projects? I'm leaning against this because
1) it creates two places one must look for dependencies
2) it leaves us open to one developer updating a package and breaking some dependency
That said, if anyone can report a good reason to start using NuGet in a TFS environment, I will happily present your ideas to my team as if they were my own (joke).
Nuget 1.6 now allows for packages not present to be downloaded dynamically upon build. So you can now check in to source control without the .dlls, but the build itself will pull the correct package.
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages