Tfs 构建代理文件夹中存在大量 NuGet.exe 版本的原因是什么？
What is the reason behind the multitude of NuGet.exe versions within the Tfs build agent folder?
我正在努力了解 Tfs 的 VNext 构建如何在幕后处理 NuGet.exe 个版本。
我正在 运行安装 Tfs 2018 (16.122.27102.1) 本地服务器。
我的代理在我的机器上 运行ning（作为 windows 服务）位于“C:\dev\tfs_bld_agents\scully\”
如果我理解正确，“Nuget 工具安装程序”(1) 将确保构建任务中指定的 NuGet.exe 版本（在本例中为 4.3.0）将安装在构建定义的位置由代理执行。
随后的构建任务“NuGet Restore”(2) 将 运行 之前构建任务(1) 安装的 NuGet.exe 并执行 NuGet 恢复命令。
但是，如果我在磁盘“C:\dev\tfs_bld_agents\scully\”上搜索构建代理的根文件夹，我会找到一系列不同版本的 NuGet.exe
- 3.3.0
- 3.5.0
- 4.0.0
- 4.3.0
NuGet.exe 版本所在的目录是：
这种行为的原因是什么，即在构建代理文件夹中有所有这些不同的版本，看到我的构建定义指定的 NuGet.exe 版本只是版本 4.3.0？
假设我们没有（或者在旧的 Tfs 版本中不能）运行“NuGet 工具安装程序”构建任务，Tfs 构建代理将如何找出在哪里可以找到 NuGet.exe 在机器上?
这些 NuGet.exe 版本默认包含在 NuGet Tool Installer 任务和 NuGet 任务中。当您对构建进行排队时，构建代理会下载构建所需的任务，然后您将看到这些 NuGet.exe 个版本。
所以我进行了一些测试，试图跟踪在“Nuget 工具安装程序”Tfs 构建任务中使用不同版本的 NuGet 时发生的情况。对于基线，使用了 Tfs2018 (16.122.27102.1) 构建代理（服务类型），只是提取和配置。
配置构建代理后，您的代理目录中将有以下 NuGet.exe：
NuGet.exe 版本：3.3.0 (3.3.0.0212) - 注意：这是在配置代理之后，这里没有构建 运行！
然后我开始设置将由特工 mulder 执行的构建定义。构建定义包含“NuGet 工具安装程序”构建任务。我的第一次尝试是指定 NuGet 2.8.6，然后 运行“NuGet 工具安装程序”构建任务。
此任务完成后，我们在构建代理文件夹中发现以下 NuGet.exe 个工件：
- NuGetInstaller
- NuGetToolInstaller
- 以及我们请求的 NuGet 版本，在位置提供...\_tool\NuGet.8.6\x64\nuget.exe
从现在开始，...\_tasks\ 文件夹的内容似乎在 NuGet.exe 版本方面保持不变，无论您指定哪个版本。
唯一明显的变化是，添加 每个 新版本你 select 在此位置...\_tool\NuGet\{请求的版本}\x64\nuget.exe。
因此，如果我们煞费苦心地 select “NuGet 工具安装程序”构建任务中的每个可能版本并 运行 它，我们最终会得到如下所示的分布：
关于代理 运行 在“NuGet 工具安装程序”构建任务中生成的日志记录，突出的事实是在 NuGet 版本中的每次切换后，都会出现以下消息：预置 PATH 环境变量。我假设目的是指向磁盘上的 selected NuGet.exe 版本。在版本 2.8.6 的情况下，我们看到以下内容：
Prepending PATH environment variable with directory: C:\TfsBuild\mulder\_work\_tool\NuGet.8.6\x64
那么如果我们恢复到特定版本会怎样？假设从 v4.5.1 到 v2.8.6 - 它会清理某些版本吗？
不。它保持一切完好无损，但确实再次修改 PATH 变量以指向您恢复到的正确版本。
Prepending PATH environment variable with directory: C:\TfsBuild\mulder\_work\_tool\NuGet.8.6\x64
一个有趣的现象是您无法在 PATH 环境变量中看到这些 "Prepending" 更改。
但是，如果您 运行 在调试中构建（通过将 system.debug 变量设置为 true），您会看到一些有趣的细节。这一次我可以看到变量确实在现有 PATH 变量（在环境变量 GUI 中可见）的前面，最后还有 2 个。
调试日志看起来像这样：
Prepending PATH environment variable with directory: C:\TfsBuild\mulder\_work\_tool\NuGet.8.6\x64
new Path:
C:\TfsBuild\mulder\_work\_tool\NuGet.8.6\x64;
C:\TfsBuild\mulder\externals\git\cmd;
.
..
<The existing paths variables>
..
.
C:\TfsBuild\mulder\bin;
C:\TfsBuild\mulder\bin
因此，它似乎检索了现有的 PATH 环境变量，然后在 运行 构建时将“新”所需变量插入它们前面。
显然 Tfs 构建非常擅长确保手头始终有正确的 NuGet.exe 版本，但清理旧版本并不是它的强项:-)
我正在努力了解 Tfs 的 VNext 构建如何在幕后处理 NuGet.exe 个版本。
我正在 运行安装 Tfs 2018 (16.122.27102.1) 本地服务器。 我的代理在我的机器上 运行ning（作为 windows 服务）位于“C:\dev\tfs_bld_agents\scully\”
如果我理解正确，“Nuget 工具安装程序”(1) 将确保构建任务中指定的 NuGet.exe 版本（在本例中为 4.3.0）将安装在构建定义的位置由代理执行。
随后的构建任务“NuGet Restore”(2) 将 运行 之前构建任务(1) 安装的 NuGet.exe 并执行 NuGet 恢复命令。
但是，如果我在磁盘“C:\dev\tfs_bld_agents\scully\”上搜索构建代理的根文件夹，我会找到一系列不同版本的 NuGet.exe
- 3.3.0
- 3.5.0
- 4.0.0
- 4.3.0
NuGet.exe 版本所在的目录是：
这种行为的原因是什么，即在构建代理文件夹中有所有这些不同的版本，看到我的构建定义指定的 NuGet.exe 版本只是版本 4.3.0？
假设我们没有（或者在旧的 Tfs 版本中不能）运行“NuGet 工具安装程序”构建任务，Tfs 构建代理将如何找出在哪里可以找到 NuGet.exe 在机器上?
这些 NuGet.exe 版本默认包含在 NuGet Tool Installer 任务和 NuGet 任务中。当您对构建进行排队时，构建代理会下载构建所需的任务，然后您将看到这些 NuGet.exe 个版本。
所以我进行了一些测试，试图跟踪在“Nuget 工具安装程序”Tfs 构建任务中使用不同版本的 NuGet 时发生的情况。对于基线，使用了 Tfs2018 (16.122.27102.1) 构建代理（服务类型），只是提取和配置。
配置构建代理后，您的代理目录中将有以下 NuGet.exe： NuGet.exe 版本：3.3.0 (3.3.0.0212) - 注意：这是在配置代理之后，这里没有构建 运行！
然后我开始设置将由特工 mulder 执行的构建定义。构建定义包含“NuGet 工具安装程序”构建任务。我的第一次尝试是指定 NuGet 2.8.6，然后 运行“NuGet 工具安装程序”构建任务。
此任务完成后，我们在构建代理文件夹中发现以下 NuGet.exe 个工件：
- NuGetInstaller
- NuGetToolInstaller
- 以及我们请求的 NuGet 版本，在位置提供...\_tool\NuGet.8.6\x64\nuget.exe
从现在开始，...\_tasks\ 文件夹的内容似乎在 NuGet.exe 版本方面保持不变，无论您指定哪个版本。
唯一明显的变化是，添加 每个 新版本你 select 在此位置...\_tool\NuGet\{请求的版本}\x64\nuget.exe。 因此，如果我们煞费苦心地 select “NuGet 工具安装程序”构建任务中的每个可能版本并 运行 它，我们最终会得到如下所示的分布：
关于代理 运行 在“NuGet 工具安装程序”构建任务中生成的日志记录，突出的事实是在 NuGet 版本中的每次切换后，都会出现以下消息：预置 PATH 环境变量。我假设目的是指向磁盘上的 selected NuGet.exe 版本。在版本 2.8.6 的情况下，我们看到以下内容：
Prepending PATH environment variable with directory: C:\TfsBuild\mulder\_work\_tool\NuGet.8.6\x64
那么如果我们恢复到特定版本会怎样？假设从 v4.5.1 到 v2.8.6 - 它会清理某些版本吗？ 不。它保持一切完好无损，但确实再次修改 PATH 变量以指向您恢复到的正确版本。
Prepending PATH environment variable with directory: C:\TfsBuild\mulder\_work\_tool\NuGet.8.6\x64
一个有趣的现象是您无法在 PATH 环境变量中看到这些 "Prepending" 更改。 但是，如果您 运行 在调试中构建（通过将 system.debug 变量设置为 true），您会看到一些有趣的细节。这一次我可以看到变量确实在现有 PATH 变量（在环境变量 GUI 中可见）的前面，最后还有 2 个。
调试日志看起来像这样：
Prepending PATH environment variable with directory: C:\TfsBuild\mulder\_work\_tool\NuGet.8.6\x64
new Path:
C:\TfsBuild\mulder\_work\_tool\NuGet.8.6\x64;
C:\TfsBuild\mulder\externals\git\cmd;
.
..
<The existing paths variables>
..
.
C:\TfsBuild\mulder\bin;
C:\TfsBuild\mulder\bin
因此，它似乎检索了现有的 PATH 环境变量，然后在 运行 构建时将“新”所需变量插入它们前面。
显然 Tfs 构建非常擅长确保手头始终有正确的 NuGet.exe 版本，但清理旧版本并不是它的强项:-)