We have a large number of solutions in our source control, which all use NuGet packages from a custom source (http://nugetserver/nuget). All solutions restore and build successfully locally within Visual Studio.
Using the new TFS 2015, our build definition looks like this:
The NuGet Installer step is there for us to restore our packages from a custom resource:
There is however no NuGet.exe file in the custom NuGet server directory. As suggested here tried just setting the -source to "https://www.nuget.org/api/v2/". We receive the same error at build whichever source we use:
You're specifying a command line argument in the "Path to NuGet.exe" field. That field should be used if you want to use a different version of NuGet than the one that's baked into the build agent.
What you need to do to solve your problem is:
Add your custom NuGet server to the machine's NuGet.config
or
Add your custom NuGet server to the application's NuGet.config.
See the NuGet docs for more info.
You're specifying the command line in the wrong field. That field is to use different version of NuGet.exe. You need to put your command in the NuGet Arguments field.
Additionally you might want to also add the default NuGet Feed to the available sources like this:
-source "https://www.nuget.org/api/v2/;http://nugetserver/nuget"
Related
So I have an Azure Artifacts feed. This feed has some packages. One if it is Newtonsoft.Json lets say 10.0.4 version. The feed is set up with an upstream source for Nuget.
When I add this feed to my project, my expectation is that when I want to get NewtonSoft latest, I would be able to get it. However, in Visual Studio or Nuget Restore, it fails to see any other version. The only version it can see is 10.0.4. I am expecting that since I specified an upstream source, it would get the packages from upstream.
I tried unlisting the 10.0.4 version, now it says newton soft is not even found.
What am I missing? What could be going on here?
For me that was a problem with permissions to the Azure Artifacts package repo.
If you are part of a group which has "Reader" access to the Azure Artifacts package repository, your nuget restores or npm installs (for JavaScript packages) WILL NOT be able to add packages to the Azure Artifacts package repository mirror/proxy.
Set the permissions of your teams/people with access to the Azure Artifacts package repository one level higher than "Reader" - set them to "Collaborator":
This is an error that's easy to miss since if you are the Artifacts package repo creator, you won't get any access errors other people might be having because you're the owner of the repo (in the picture below I'm Artur)
Once you've enabled an upstream source, any user connected to your feed can install a package from the remote feed, and your feed will save a copy.
If you add your Artifacts feed in the Package sources in Visual Studio. When you search for package NewtonSoft within your artifact feed in Visual Studio. It is the default behavior that you can only see the saved copy of package NewtonSoft.
To install the NewtonSoft latest, you can search and install it in the nuget.org package source(You need to add nuget.org to Package sources if it is not listed in the package source list )
Or you can use command line to install the NewtonSoft latest by specifying the version parameter. See below:
Install-Package Newtonsoft.Json -Version 12.0.3
You can also directly add NewtonSoft latest version as package dependency to your project by editting .csproj or package.config file. When you restore your packages. if the NewtonSoft latest is not found in your Artifacts feed, it will be downloaded from the upstream source.
I am attempting to create my first ever agent build using on my my asp.net mvc projects. The agent is on my own computer. Everything appears to work fine up until after the nuget restore.
Picture:
It is telling me that my System.Web.MVC assembly could not be located. Since this is of course my first build I am unsure of what to do or what could cause this issue especially since it builds fine locally in VS.
Any help would be greatly appreciated:
TFS Version: 16.122.27102.1
You can follow steps below to locate the cause of the issue and resolve it:
1.The Nuget 4.3.0 you're using is too old. Instead you should use recommended 5.7.0. (Modify your Use Nuget Task)
2.Check log of your restore step.
The missing System.Web.MVC comes from Microsoft.AspNet.Mvc nuget package, so you should make sure this package is actually downloaded/installed. And make sure the hintPath in your csproj is correct compared to the installation path of the nuget package.
Also make sure you're restoring for whole solution instead of one specific project.
Check whether you added packages folder into source control. The packages folder in SolutionDir should not be added into source control! It will affect the restore stop.
3.Check MSBuild arguments of Build task, you can share the arguments and build logs here if convenient.
I used NuGet to add CastleWindsor to a project. Eveything works ok.
When I check it into tfs, I get the following message.
Unable to find version '3.3.3' of package 'Castle.Core'.
Any idea how I can get the build server to get the new version of Castle.Core?
First just as Dave commented, please check if you have add the nuget install task in your build definition and before your build task.
Also make sure you are using the right version of Nuget. For example, if you already use V3.0 and the config file are still point to V2.0. You will get this error.
Moreover, double check if the packages can be restored successfully on you dev PC and build agent manually, you can also compare the nuget.config file on your TFS server and dev PCs to see if there is any difference between them. The nuget.config file locates at "%APPDATA%\NuGet\NuGet.Config".
TFS2012 does not restore the nuget packages automatically, you need to add a build step to call the nuget command to restore the nuget packages. Refer to this link for details: Package Restore with Team Foundation Build.
With TFS 2013 and later, packages are automatically restored by
default during build, provided that you're using a Team Build Template
for Team Foundation Server 2013 or later.
If you're using a previous version of build templates (such as in a
project that's been migrated from earlier versions of TFS), you'll
need to also migrate those build templates to TFS 2013. This
essentially means recreating the custom parts of the Build Templates
using the appropriate template for your source control (TFVC or Git).
For earlier version of TFS, you can simply include a build step to
invoke command-line restore as described earlier.
I'm looking for advice on how to have team build 2013 use a pre-compiled common that is not checked in or part of the workspace.
Everything we build is QNX based and we are refactoring out a common set of components to be shared across all projects. I've looked at Go and NuGet but that seems like a lot effort for something like this.
What is the best way to pull a prebuilt common into a TFS Team Build?
So you would nuget "publish" a package.
https://docs.nuget.org/create/creating-and-publishing-a-package
then your build would nuget restore using a packages.config file (aka, NOT a .sln file)
nuget restore [<solution>|<packages.config file>]
https://docs.nuget.org/consume/command-line-reference
What VS (in a .sln file) is auto-voodooing some of this for you.
But using command line nuget (especially for the restore)....is a way to get a package out of nuget if you're build isn't based on .sln file.
Another way to think about it is...when you run "nuget install" or "nuget update", VS is auto-voodooing you a packages.config file. While you might look at the file and find it interesting, you're not consumed on how it works in the background of VS. But if you want to manually pull nuget packages....you will be very interested in how it is created.
What I would do as a test would be:
Create a dummy .sln,csproj file.
Nuget add a few random packages (using "Manage Nuget Packages for this solution).
Take that packages.config that was auto-voodoo created for you.... and move it to a clean directory.
See if you can run nuget.exe restore on it, and get/pull the packages (aka, you're testing that you can do a pull... without a .sln file being involved).
If that works...than it becomes of matter of creating your own nuget repository..creating your own published-package...and repeating #4 above to get that package out.
Make sense?
So I have these files in a clean directory:
.\packages.config
.\.nuget\NuGet.Config
.\.nuget\NuGet.exe
.\.nuget\NuGet.targets
Then I run in the comamand-window:
.\.nuget\nuget.exe restore .\packages.config -PackagesDirectory .\MyPackages
And all the packages listed in "packages.config" will download to : .\MyPackages
Note, if you have a custom nuget repository, that will need to be configured...but cross that bridge when you get there.
So the past few days i've been setting up NuGet, making packages of our internal libraries, updating our projects, getting our TFS Build server to Build. all of this is awesome! Now I have a problem though, before NuGet and package restore I could search TFS for the .dll files, as an example I could search for Company.Common.dll in TFS and find all projects that utilized this dll with the following command:
tf dir "$/*Company.common.dll" /recursive
/server:http://tfs-server:8080
Now after we have started using NuGet and using package restore the dll file Company.Common.dll will not be present in TFS in the projects that uses it. that means I can't use the above search command to find the .dll file I want to update
I was contemplating writing a powershell script that would find all packages.config files in TFS and download them to a folder structure indicating where in TFS the different projects are located. Then I would traverse the packages.config file to figure out what projects used the specific NuGet package I wanted to update.
The reason for this is ofcourse that all our projects should have the Common.dll updated when there is an update too it.
What I would like to know is if anyone has already solved this "problem", so I don't have to invent the wheel again, or perhaps have some perspective or constructive comments on this. I guess the core question is this:
How do you handle updating a package across ALL projects, when there are multiple teams that create / update projects in TFS?
One solution would be to use the "repositoryPath" NuGet config settings and make it point to a central UNC share. More details here # http://docs.nuget.org/docs/release-notes/nuget-2.1.
You can use NuGet.exe Update packageName -RepositoryPath xxx -Source xxx command to update the specific package if needed.