MSBuild on CI Server can't find AL.exe

Question

I'm having 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: Task could not find "AL.exe" using the SdkToolsPath "" or the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A". Make sure the SdkToolsPath is set and the tool exists in the correct processor specific location under the SdkToolsPath and that the Microsoft Windows SDK is installed

I've found similar reports from a year ago when people were upgrading to .NET 3.5, for example this one. In that case, installing the latest SDK solved the issue, however I have already installed the latest SDK (Microsoft Windows SDK for Windows 7 and .NET Framework 4) on my build server. The MSBuild tools are all there on the server, in a folder called

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

and AL.exe exists in

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

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

Answer 1

As you have install the latest SDK (I'm assuming that's v7.1)

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

3. cd Setup

4. WindowsSdkVer -version:v7.1

This will tell msbuild to use that version of the tools without needing to do any scary registry editing.

Answer 2

Even though the question is quite old but it still appears in the top of google search results so I decided to post my solution as well. I have trapped into same issue while during TeamCity setup on Windows Server 2016 and Windows 10 Pro.

I have installed Microsoft Build Tools 2015 and Windows 10 SDK (Only tools for .NET 4.6.2) and got the error from question.

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

After setting environment variable MSBuild was able to resolve all needed tools including AL.exe and build succeeded.

Please let me know if same can be achieved by setting values in registry, but otherwise environment variables also works very well in this case and no installation of VS is needed.

Answer 3

You also need to apply the following registry fix to update msbuild to point to the V7.1 sdk 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)"

Answer 4

I had the same problem there, here's my simple answer to this.

After you have installed the 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)

Answer 5

Follow the below steps. This worked perfectly to me. Saved my time.

1- Right-click the My Computer icon and choose Properties, or in Windows Control Panel, choose System.

2- Choose Advanced system settings.

3- On the Advanced tab, click Environment Variables.

4- Click New to create a new environment variable under User variable section.

5- Variable name: TargetFrameworkSDKToolsDirectory

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

Variable value depends on your SDK installation path.

7- Click OK and Save all windows.

8- Restart Visual Studio.

Answer 6

I have a simple, effective fix.

The problem seems to be that the tools version delivered with Visual Studio is version 7.0A, while the version delivered with the Windows SDK is version 7.1. That's all very well, but MSBuild.exe is still looking for the version 7.0A registry keys, which don't exist. This has to be a bug!

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

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

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

Job done. MSBuild now works perfectly on the TeamCity server.

Answer 7

Add a system env variable TargetFrameworkSDKToolsDirectory

like this:

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

restart VS

Answer 8

Ran into the same issue setting up a new build server on Windows 10. Found and installed the latest (at the time) Microsoft Windows SDK for Windows 7 and .NET Framework 4 and that solved the problem.

Answer 9

We recently had this problem trying to get our .Net 4.0 builds working. We found that the location of al.exe had changed between where the original MSBuild that came with .Net 4.0 looks, 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 had already installed without success (the one you mentioned), the only solution we could think of was to install Visual Studio on the build agents. We put Visual Studio 2010 Express (to keep the installation as lightweight as possible) on there and the problem went away. Not a pretty solution, but it did work - installing VS2010 also installs the SDK tools of the specific version that MSBuild appears to be looking for.

This is a problem that really shouldn't happen, but there didn't seem to be a way of making MSBuild look in the correct place for the tools, even hacking around in the registry.