CI 服务器上的 MSBuild 找不到 AL.exe答案

【问题标题】：MSBuild on CI Server can't find AL.exeCI 服务器上的 MSBuild 找不到 AL.exe
【发布时间】：2011-02-28 12:14:12
【问题描述】：

我的 TeamCity CI 构建服务器出现问题，在编译期间出现以下错误：

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2342, 9)：错误 MSB3086：任务无法使用 SdkToolsPath“”或注册表项找到“AL.exe” “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A”。确保设置了 SdkToolsPath，并且该工具存在于 SdkToolsPath 下的正确处理器特定位置，并且安装了 Microsoft Windows SDK

我发现一年前人们升级到 .NET 3.5 时的类似报告，例如 this one。在这种情况下，安装最新的 SDK 解决了这个问题，但是我已经在我的构建服务器上安装了最新的 SDK (Microsoft Windows SDK for Windows 7 and .NET Framework 4)。 MSBuild 工具都在服务器上的一个名为

的文件夹中

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319

而AL.exe存在于

C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 工具

但是，错误消息中提到的注册表项不存在。因此，似乎 MSBuild 的安装/配置有问题。此错误仅发生在具有嵌入式资源且需要 AL.exe 的项目中。

【问题讨论】：

这个问题今天重新出现在我们面前，经过几个晚上的 .NET 补丁，我们不得不在接受的答案中重新运行命令。很奇怪！

标签： winapi .net-4.0 msbuild teamcity

【解决方案1】：

您已经安装了最新的 SDK（我假设是 v7.1）

从“开始”菜单转到“Microsoft Windows SDK v7.1”

选择“Windows SDK 7.1 命令提示符”并输入

cd 设置

WindowsSdkVer -version:v7.1

这将告诉 msbuild 使用该版本的工具，而无需进行任何可怕的注册表编辑。

【讨论】：

这非常优雅，比我的注册表破解要好得多。一个凡人怎么会知道这些东西？ PS。既然您认为我的问题值得回答，请考虑给它投票。
这是我运行 Windows 2003 64 位服务器的解决方案的一半。 Msbuild 在注册表的 32 位部分 (HKEY_LOCAL_MACHINE\Software\Wow6432Node) 中寻找注册表项，而 WindowsSdkVer 正在设置 64 位部分。我必须手动更新 HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\MSBuild\ToolsVersions\4.0 中的路径才能完成这项工作。
在更高版本的 .NET 中删除了 Windows SDK 命令行。如果您使用的是 msbuild proj 文件，请尝试从任务中删除 ToolsVersion，它为我解决了这个问题。我想它没有尝试使用特定的（不存在的）SDK，而是使用了最新安装的 SDK。

【解决方案2】：

尽管这个问题已经很老了，但它仍然出现在谷歌搜索结果的顶部，所以我决定也发布我的解决方案。在 Windows Server 2016 和 Windows 10 Pro 上设置 TeamCity 时，我遇到了同样的问题。

我已安装 Microsoft Build Tools 2015 和 Windows 10 SDK（仅限 .NET 4.6.2 的工具）并从问题中得到错误。

缺少的难题是设置环境变量：TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools。

设置环境变量后，MSBuild 能够解析所有需要的工具，包括 AL.exe，并且构建成功。

请告诉我是否可以通过在注册表中设置值来实现相同的目的，否则环境变量在这种情况下也可以很好地工作，并且不需要安装 VS。

【讨论】：

我们是在这里讨论系统环境变量还是构建配置设置 -> 参数？最后一个env. 会在TargetFrameworkSDKToolsDirectory 之前添加，对吧？
我的评论是正确的，补充说那里解决了问题。
@CularBytes，我不完全理解你的第一条评论。我已将该环境变量添加到运行 TC 的用户变量中。它也可以作为系统变量添加。我很高兴它有所帮助。
我在 Windows 2012 R2 上使用 TeamCity 2017.1 时遇到了类似的问题。我设置了 env 值，然后直到我重新启动两个 Team City 服务，msbuild 才能看到新变量。

【解决方案3】：

您还需要应用以下注册表修复程序来更新 msbuild 以指向 V7.1 sdk 值。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0]
"MSBuildToolsPath"="C:\\WINDOWS\\Microsoft.NET\\Framework\\v4.0.30319\\"
"MSBuildToolsRoot"="C:\\WINDOWS\\Microsoft.NET\\Framework\\"
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1@InstallationFolder)"
"MSBuildRuntimeVersion"="4.0.30319"
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDK-NetFx40Tools-x86@InstallationFolder)"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDKNetFx35Tools@InstallationFolder)"
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MSBuild\\ToolsVersions\\4.0@MSBuildToolsPath)"

【讨论】：

【解决方案4】：

我在那里遇到了同样的问题，这是我对此的简单回答。

在 TeamCity 服务器上安装 Microsoft Windows SDK 7.1 之后。

在 Regedit 中更改此键

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\SDK40ToolsPath

到

$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx40Tools-x86@InstallationFolder)

【讨论】：

【解决方案5】：

按照以下步骤操作。这对我来说非常有效。节省了我的时间。

1- 右键单击我的电脑图标并选择属性，或在Windows 控制面板中选择系统强>。

2- 选择高级系统设置。

3- 在高级标签上，点击环境变量。

4- 点击New在用户变量部分下创建一个新的环境变量。

5- 变量名：TargetFrameworkSDKToolsDirectory

6- 变量值：TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools

变量值取决于您的 SDK 安装路径。

7- 点击OK并保存所有窗口。

8- 重启 Visual Studio。

【讨论】：

【解决方案6】：

我有一个简单有效的解决方法。

问题似乎是 Visual Studio 附带的工具版本是 7.0A 版，而 Windows SDK 附带的版本是 7.1 版。这一切都很好，但 MSBuild.exe 仍在寻找不存在的 7.0A 版注册表项。这一定是个bug！

查看我的注册表，V6.0 和 V7.1 的所有信息都存在且正确。所以我的解决方案很简单。我创建了一个注册表链接，它为 7.1 键设置了别名。

使用内置工具无法创建注册表链接，因此我从here 下载了一个名为“regln”的小实用程序。

C:>regln-x86.exe "\Registry\Machine\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A" "\Registry \Machine\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1"

工作完成。 MSBuild 现在可以在 TeamCity 服务器上完美运行。

【讨论】：

【解决方案7】：

添加系统环境变量TargetFrameworkSDKToolsDirectory

像这样：

TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools

重启VS

【讨论】：

【解决方案8】：

在 Windows 10 上设置新的构建服务器时遇到了同样的问题。找到并安装了最新的（当时）Microsoft Windows SDK for Windows 7 and .NET Framework 4 并解决了问题。

【讨论】：

【解决方案9】：

我们最近在尝试使我们的 .Net 4.0 构建工作时遇到了这个问题。我们发现 al.exe 的位置在 .Net 4.0 附带的原始 MSBuild 与 .Net 4.0 的 Visual Studio SDK（后来发布）之间发生了变化。

由于 SDK 工具的唯一独立安装是我们已经安装但没有成功的那个（您提到的那个），我们能想到的唯一解决方案是在构建代理上安装 Visual Studio。我们将 Visual Studio 2010 Express（以使安装尽可能轻量）放在那里，问题就消失了。不是一个漂亮的解决方案，但它确实有效 - 安装 VS2010 还会安装 MSBuild 似乎正在寻找的特定版本的 SDK 工具。

这是一个真正不应该发生的问题，但似乎没有办法让 MSBuild 找到工具的正确位置，甚至在注册表中四处乱窜。

【讨论】：

不幸的是，在这台服务器上安装 Visual Studio 可能是不可能的。不过，感谢您提供的信息。