What is the reason behind the multitude of NuGet.exe versions within the Tfs build agent folder?

Question

I am grappling to understand how Tfs’s VNext build handles NuGet.exe versions under the hood.

I am running a Tfs 2018 (16.122.27102.1) on-prem server. My agent is running (as a windows service) on my machine on the location “C:\dev\tfs_bld_agents\scully\”

If I understand it correctly the “Nuget tool installer” (1) will ensure that the NuGet.exe version specified in the build task (in this case 4.3.0), will be installed where this build definition is executed by an agent.

The subsequent build task “NuGet Restore”(2) will then run the NuGet.exe installed by the previous build task(1) and will execute the NuGet restore command.

If, however, I search through the build agent's root folder on disk “C:\dev\tfs_bld_agents\scully\” I find an array of different versions of NuGet.exe

• 3.3.0
• 3.5.0
• 4.0.0
• 4.3.0

Directories, where a version of NuGet.exe resides, are:

What is the reason for this behaviour i.e. having all these different versions within the build agent folder, seeing that the NuGet.exe version specified by my build definition was only version 4.3.0?

Assuming that we for instance do not (or cannot in older Tfs versions) run the “NuGet Tool Installer” build task, how will the Tfs build agent go about figuring out where to find a NuGet.exe on the machine?

Answer 1

These NuGet.exe versions are included in the NuGet Tool Installer task and NuGet task by default. When you queue a build, build agent downloads the tasks build needs, then you will see these NuGet.exe versions.

Answer 2

So I performed some tests attempting to track what happens when you use different versions of NuGet within the “Nuget tool installer” Tfs build task. For the baseline, a Tfs2018 (16.122.27102.1) build agent (of type service) was used, just extracted and configured.

After configuring the build agent, you will have the following NuGet.exe in your agent directory: NuGet.exe version: 3.3.0 (3.3.0.0212) - Note: this is just after the agent was configured, no builds have been run here!

I then proceeded to set up a build definition that will be executed by agent mulder. The build definition contained the “NuGet Tool Installer” build task. My first try was to specify NuGet 2.8.6 and then run the “NuGet Tool Installer” build task.

After this task was completed, we find the following NuGet.exe artifacts within our build agent folder:

• NuGetInstaller
• NuGetToolInstaller
• As well as the NuGet version we requested, provided on location ...\_tool\NuGet\2.8.6\x64\nuget.exe

From this point onwards, the content of the ...\_tasks\ folder seems to remain constant in regards to NuGet.exe versions, regardless of which version you specify.

The only obvious change being, the addition of every new version you select within this location ...\_tool\NuGet\{version requested}\x64\nuget.exe. So if we painstakingly select each possible version in the “NuGet Tool Installer” build task and run it, we will end up with a spread that looks like this:

Regarding the logging produced by the agent running the “NuGet Tool Installer” build task, the thing that stands out is the fact that after each switch in the NuGet version, the following message appears: Prepending PATH environment variable. I assume the purpose being to point to the selected NuGet.exe version on disk. In the case of version 2.8.6 we see the following:

Prepending PATH environment variable with directory: C:\TfsBuild\mulder\_work\_tool\NuGet\2.8.6\x64

So what happens if we revert back to a specific version? Let say from v4.5.1 to v2.8.6 - does it clean up some versions? No. It leaves everything intact but does modify the PATH variable again to point to the correct version you reverted to.

Prepending PATH environment variable with directory: C:\TfsBuild\mulder\_work\_tool\NuGet\2.8.6\x64

An interesting phenomenon is that you cannot see these "Prepending" changes in your PATH environment variable. If you, however, run the build in debug (by flipping the system.debug variable to true) you see some interesting details. This time around I can see that the variable(s) are indeed slipped in front of the existing PATH variables (that are visible in the environment variables GUI), as well as 2 more at the end.

Debug logging looks something like this:

Prepending PATH environment variable with directory: C:\TfsBuild\mulder\_work\_tool\NuGet\2.8.6\x64
new Path: 
C:\TfsBuild\mulder\_work\_tool\NuGet\2.8.6\x64;
C:\TfsBuild\mulder\externals\git\cmd; 
.
..
<The existing paths variables>
..
.
C:\TfsBuild\mulder\bin;
C:\TfsBuild\mulder\bin

It thus seems to retrieve the existing PATH environment variable, and then slot in the “new” required variables in front of them while running the build.

Clearly Tfs build is very good at ensuring that there is always a correct version of NuGet.exe at hand, but cleaning up old versions is not its strong suit :-)