MSBuild on CI server cannot find AL.exe

I had a problem on my TeamCity CI build server, where during compilation I get the following error:

C: \ WINDOWS \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets (2342, 9): error MSB3086: the task could not find "AL.exe using SdkToolsPath" or the registry key "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDK \ Windows \ v7.0A. "Make sure that SdkToolsPath is installed and the tool exists in the right place for the specific processor in SdkToolsPath and the Microsoft Windows SDK is installed.

I found similar reports a year ago when people upgraded to .NET 3.5, like this one . In this case, installing the latest version of the SDK solved the problem, however, I already installed the latest version of the SDK ( Microsoft Windows SDK for Windows 7 and .NET Framework 4 ) on my build server. MSBuild tools are located on the server in a folder with the name

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

and AL.exe exists in

C: \ Program Files \ Microsoft SDK \ Windows \ v7.1 \ Bin \ NETFX 4.0 Tools

However, the registry key mentioned in the error message does not exist. So it seems that something is wrong with the installation / configuration of MSBuild. This error occurs only for projects with embedded resources that require AL.exe.

+44
winapi msbuild teamcity
Jun. 07 2018-10-06T00:
source share
7 answers

How did you install the latest SDK (I assume v7.1)

  • Go to the "Microsoft Windows SDK v7.1" from the Start menu
  • Select "Windows SDK 7.1 Command Prompt" and enter
  • cd setup

  • WindowsSdkVer -version: v7.1

This will tell msbuild to use this version of the tools without requiring any scary registry editing.

+52
Jun 23 '10 at 15:25
source share

Although the question is quite old, it still appears at the top of Google search results, so I decided to post my solution. I got the same problem while installing TeamCity on Windows Server 2016 and Windows 10 Pro.

I installed Microsoft Build Tools 2015 and the Windows 10 SDK (Tools for .NET 4.6.2 only) and received an error message.

An invalid puzzle was to set an environment variable: TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools .

After setting the environment variable, MSBuild was able to resolve all the necessary tools, including AL.exe, and complete the build.

Please let me know if this can be achieved by setting values ​​in the registry, but otherwise the environment variables also work very well in this case, and VS installation is not required.

+11
Feb 09 '17 at 15:29
source share

You also need to apply the following registry fix to update msbuild to specify sdk V7.1 values.

 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)" 
+6
Sep 21 '10 at 10:16
source share

I had the same problem, here is my simple answer to this question.

After installing Microsoft Windows SDK 7.1 on the TeamCity server.

In Regedit Change This Key

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

to

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

Look at the picture, I got my first TeamCity Building project with this! (was v7.0a) I have a photo to show how simple it was.

 > Oops! Your picture couldn't be submitted because: > > We're sorry, but as a spam prevention mechanism, new users aren't > allowed to post images. Earn more than 10 reputation to post images. 
+4
Mar 05 '12 at 23:32
source share

I have a simple, effective fix.

The problem is that the version of the tools that comes with Visual Studio is version 7.0A, and the version that comes with the Windows SDK is version 7.1. All this is very good, but MSBuild.exe is still looking for registry keys version 7.0A that are not there. This must be a mistake!

In my registry all the information for V6.0 and V7.1 is present and correct. Therefore, my solution is simple. I created a registry link that makes an alias of 7.1 keys.

It is not possible to create registry links using the built-in tools, so I downloaded a small utility called 'regln' from here .

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

Work is done. MSBuild now works great on TeamCity Server.

+3
Jun 14 '10 at 22:24
source share

Enable the same problem by setting up a new build server on Windows 10. I found and installed the latest (at that time) Microsoft Windows SDK for Windows 7 and .NET Framework 4 , and this solved the problem.

+1
Feb 17 '16 at 15:05
source share

We recently ran into this problem trying to get our .Net 4.0 builds to work. We found that the location of al.exe changed between where the original MSBuild that ships with .NET 4.0 and the Visual Studio SDK for .Net 4.0 (which was released later).

Since the only standalone installation of the SDK tools available is the one we already installed without success (the one you mentioned), the only solution we could think of was to install Visual Studio on build agents. We host Visual Studio 2010 Express (so that installing the installation as light as possible as little as possible) and the problem goes away. Not a pretty solution, but it really worked - installing VS2010 also installs the SDK tools of the specific version that MSBuild is looking for.

This is a problem that really shouldn't happen, but there seemed to be no way to make MSBuild look in the right place for tools, even hacking into the registry.

0
Jun 07 '10 at 0:20
source share



All Articles