CI服务器上的MSBuild无法找到AL.exe

Question

我在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。

Answer 1

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

  

  
1. 从“开始”菜单
转到“Microsoft Windows SDK v7.1”   
2. 选择“Windows SDK 7.1命令提示符”并输入
  

3.     

   cd Setup

     

  

4.     

   WindowsSdkVer -version：v7.1

     

  

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

Answer 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。

Answer 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)"

Answer 4

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

在TeamCity Server上安装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)

Answer 5

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

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

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

使用内置工具创建注册表链接是不可能的，所以我从here下载了一个名为'regln'的小工具。

  

C：＆gt; regln-x86.exe“\ Registry \ Machine \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.0A”“\ Registry   \ Machine \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.1“

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

Answer 6

请遵循以下步骤。这对我来说非常有效。节省了时间。

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

2-选择高级系统设置。

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

4-单击 New ，在 User variable部分下创建一个新的环境变量。

5-变量名称： TargetFrameworkSDKToolsDirectory

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

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

7-单击确定，然后保存所有窗口。

8- 重新启动 Visual Studio。

Answer 7

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

Answer 8

我们最近遇到了这个问题，试图让我们的.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在工具的正确位置看起来，甚至在注册表中进行黑客攻击。

Answer 9

添加系统环境。变量TargetFrameworkSDKToolsDirectory

像这样：

TargetFrameworkSDKToolsDirectory = C：\ Program Files（x86）\ Microsoft SDKs \ Windows \ v10.0A \ bin \ NETFX 4.6.2工具

重启VS