We are hosting TFS 2017 Update 2 on-prem, and using on-prem build agents. The latest version of NuGet.exe is currently 4.3.0, but our build agents always default to using v4.0.0. How can I get our build agents to use the latest version of NuGet.exe?
We need to update because NuGet restore is failing when using v4.0.0, but works with v4.3.0, since we are dealing with new .Net Standard 2.0 packages. On our build server I was able to do NuGet.exe update -self to update the NuGet.exe found at C:\Builds\_work\_tool\NuGet\4.0.0\x64\nuget.exe from 4.0.0 to 4.3.0, but that C:\Builds\_work\_tool directory regularly gets deleted and recreated, so this isn't a persistent workaround.
How can I get our build agents to always use the latest version of NuGet.exe, or at least v4.3.0?
I know you're not supposed to answer with a link, but this post provides all the details you'll need, confirming that the task does indeed still use 4.0.0, how with VSTS and TFS 2018 you don't have to worry about this anymore (there's a new NuGet Installer task) and how to recreate that kind of task for VS 2017.2 (and earlier) via a PowerShell Script, Using the latest NuGet in your build
Based on Greg's linked answer, but a little bit simpler:
Add a step "NuGet Tool Installer" before the other NuGet steps, use ">=5.0.0" for the version and mark "Always download the latest matching version", this should - well - give you the latest stable version
Replace the existing "NuGet Installer" steps - this seems to be the default with "NuGet Restore" steps, just copying the settings. They seem to be totally compatible, allowing e. g. for package config or solution files to be referenced, including pattern matching
That is it. Replacing the "NuGet Installer" that requires you to specify a version with the "NuGet Restore" that just uses the NuGet.exe from the path as set in "NuGet Tool Installer" is easier. Also mind the confusing naming (NuGet Tool Installer/NuGet Installer - the two are rather different).
Having to tinker so much with the not so old TFS 2017 infrastructure is a shame.
Related
We have a .net solution with around 30 projects in it.
We have a dependency on another internal project ( not in the same solution ), for which we use TeamCity NuGet to get the latest packages.
Currently, We update all packages using nuget update-packages command with a specific version that we need and check-in our code and then TeamCity builds it.
(We commit packages too)
We are looking for a simpler solution where TeamCity can automatically update to the latest package and check-in into TFS.
I have tried using TeamCity NuGet installer but it didn't work, also, what I want is to get updates only for a specific package (not all the packages in projects).
I want to execute my NuGet update-packages command as a TeamCity build step so that it will update the packages and we don't have to do it manually every time we have a new update available.
i think best option is you can use ms build.
msbuild will allow you to publish or push the nuget package along with version to server or will do checkin to tfs which is change.
Thanks
DJM
What is the process for upgrading the default tasks loaded by Microsoft in an on-premises TFS with no internet connectivity?
According to https://learn.microsoft.com/en-us/vsts/build-release/tasks/ there are several tasks now available and supported in TFS v2015-2018/VSTS that do not appear in my TFS 2017u2 installation (specifically the Download Secure File task).
The default tasks are not shown in the Manage Extension screens and the git repo (https://github.com/Microsoft/vsts-tasks) does not appear to have any instructions for how to package and install the latest versions in an existing TFS.
Download Secure File this task is not support by TFS2017 update2 for now.
In the right of the task, there is a column called Versions which stands for the supported TFS version and VSTS for now.
I use TFS on-premises and I don't see some of these features. Why not?
Some of these features are available only on VSTS and not yet
available on-premises. Some features are available on-premises if
you have upgraded to the latest version of TFS.
Source Link
The task you need is only available/build-in with VSTS by now.
However, this task is open sourced, you could find it here. You could also build it and package it as normal extension. Take a look at below steps for your reference:
Globally install typescript and tfx-cli (to package VSTS
extensions): npm install -g typescript tfx-cli
From the suitable of the repo run npm install. This will pull down
the necessary modules for the tasks and for the build tools.
Run npm run build to compile the build tasks or build a specific
task (recommended): node make.js build --task ShellScript
Run npm run package -- --version <version> to create the .vsix
extension packages (supports multiple environments) that includes
the build tasks.
With the .vsix files, you are easy to directly upload the extension. Details about this area, you could refer here:
How do you install extension vsix files to TFS 2015 (Update 3)?
How do I use the tfs-cli (tfx) to update a TFS extension for an on-premise TFS instance?
Besides, even you have published the extension to your TFS successfully, this task may not compatible with your present version, just Giulio said, you could create a test first. Certainly, you could also create your own extension as your demands.
Look at the Contribute page: it is a bit cryptic if you are not familiar with Javascript tooling.
CAVEAT: there is no guarantee that an update Task works with your TFS version and rolling back a change is a non-trivial task. Use, at least, a separate Collection to test changes.
I am looking for some more specific support details.
I have managed to persuade our management to use Artifactory.
We currently use the following, mostly for WinForms development. We have several dozen products we support.
Visual Studio 2015 Enterprise
TFS 2012 on Prem (working to persuade management to upgrade this soon)
NuGet 3.5. with Project.JSon
I am just not sure if Artifactory can support some of the older tools we use. I can't find any details on their website that are version specific. It just says it supports "TFS".
I read mention in some samples of Packages.config, but we got rid of those bad boys some time ago. Project.json is much better. Once we move to VS 2017 the project.json goes away too.
Does Artifactory support TFS 2012? Project.Json files?
Artifactory NuGet support is agnostic of how you manage your project, the only requirement is that your builds use supported clients (like the one integrated into VS). You can deploy and resolve your own packages or have Artifactory proxy a remote location (as long as it supports the NuGet API)
TFS support is provided by the MSBuild Artifactory Plugin which collects info from your build and also enables you to resolve dependencies via Artifactory, and deploy build artifacts.
If you are on TFS2012, it's still using XAML build. Which means you need to use MSBuild Artifactory Plugin.
The MSBuild Artifactory Plugin is installed as a "Project
Template" using Visual Studio as follows:
Under Tools, choose Extensions and Updates..., select the Visual Studio Gallery source under the Online section, and run a search for
"Artifactory".
Select Artifactory Template Package extension found, and click Install.
So, instead of TFS version limitation, it should be more related to VS version.
And according to the Artifactory Template Package in VisualStudio Marketplace, which including VS2015.
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.
From this article -
"However, there are cases where it’s not actually a person who’s doing the building and who therefore can’t provide consent this way. (And where Visual Studio isn’t even installed.) The prototypical example is a build server. In that case, NuGet will also look for an environment variable called EnableNuGetPackageRestore. To enable package restore for scenarios where the Visual Studio option is not practical, set this variable to true."
How does TFS even know how to call nuget? Do I install the nuget exe?
As you've stated in a comment, "Enable NuGet Package Restore" is no longer the recommended method for accomplishing this. The NuGet docs explain it best. Basically, because that method is integrated into MSBuild, packages that extend the build will be downloaded too late. While I'm not sure what packages do this currently it appears that there are big plans for the future of NuGet (the new ASP.NET vNext custom CLR implementation is one example of where it's headed).
The good news is that the alternative is really easy to set up. If you're in VS, you literally do nothing (unless you've disabled the automatic package restore in the past). If you have a build server you just have to make some small changes to your .proj file. If you're not familiar with MSBuild it may seem challenging but it's really quite simple. The secret is this chunk of code:
<Target Name="RestorePackages">
<Exec Command=""$(ToolsHome)NuGet\NuGet.exe" restore "%(Solution.Identity)"" />
</Target>
Again, the details are in the docs (this one specifically). If you have any questions don't be afraid to reach out: the SO community is here to help!
How does TFS even know how to call nuget? Do I install the nuget exe?
No, you should enable package restore for the solution which can be done from the context menu for the solution file in the solution explorer. This will add a folder named .nuget to your solution and in this folder you will find NuGet.exe.
If you add the solution to source control and build it on a build server the NuGet.exe executable will be used by the NuGet msbuild targets to restore packages from NuGet as part of the build.
So you do not need to install NuGet on the build server - it becomes part of your project and is placed under version control.
If you set your solutions to restore NuGet packages, and then on the build server with the build account, open vs and set Allow NuGet to download missing packages during build in Visual Studio. Your builds should restore packages ok.