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.

This issue re-appeared for us today, after alst nights .NET patches, and we had to re-run the command in the accepted answer. Very strange! — Danny Tuppeny, Jan 10 '13 at 09:40

score 54 · Accepted Answer · edited Mar 06 '12 at 11:55

54

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

Go to "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 that version of the tools without needing to do any scary registry editing.

edited Mar 06 '12 at 11:55

Code Lღver

15,573
16
56
75

answered Jun 23 '10 at 15:25

AndyPook

2,762
20
23

1

That's very elegant, far better than my registry hack. How is a mere mortal supposed to know this stuff? PS. Since you thought my question was worth answering, please consider giving it an upvote. – Tim Long Jul 05 '10 at 15:26
6

This was half the solution on my server running Windows 2003 64bit. Msbuild was looking for the registry keys in the 32 bit part of the registry (HKEY_LOCAL_MACHINE\Software\Wow6432Node) and WindowsSdkVer is setting the 64 bit part. I had to manually update the paths in HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\MSBuild\ToolsVersions\4.0 to make this work. – Benjamin Wegman Nov 02 '10 at 14:22
3

The Windows SDK command line was removed in later versions of .NET. If you're using a msbuild proj file, try removing ToolsVersion from task, it solved it for me. I guess instead of trying to use a specific (non-existing) SDK, it used the latest one installed. – Sire Sep 27 '16 at 11:34

score 18 · Answer 2 · answered Feb 09 '17 at 15:29

18

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.

answered Feb 09 '17 at 15:29

Andrii Litvinov

12,402
3
52
59

Are we walking about system environment variables here or build configuration settings -> Parameters? For the last an `env.` would be added prior to `TargetFrameworkSDKToolsDirectory`, right? – CularBytes Feb 28 '17 at 21:54
My comment is correct, adding that there solves the problem. – CularBytes Feb 28 '17 at 22:38
@CularBytes, I don't completely understand you first comment. I have added that environment variable to variables of user under which TC was running. It can also be added as system variable. And I am glad it helped. – Andrii Litvinov Mar 01 '17 at 07:25
3

I had a similar issue with TeamCity 2017.1 on Windows 2012 R2. I had the set the env value and then not until I restarted both Team City services was msbuild able to see the new variables. – BrandonG Apr 18 '17 at 23:21

score 6 · Answer 3 · answered Sep 21 '10 at 10:16

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

score 4 · Answer 4 · answered Nov 13 '19 at 07:00

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.

score 4 · Answer 5 · edited May 24 '18 at 14:14

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)

edited May 24 '18 at 14:14

Wai Ha Lee

8,598
83
57
92

answered Mar 05 '12 at 23:32

poolfoot

53
4

score 3 · Answer 6 · answered Jun 14 '10 at 22:24

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.

score 2 · Answer 7 · edited Jul 08 '20 at 03:31

2

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

edited Jul 08 '20 at 03:31

Corey

1,217
3
22
39

answered Nov 27 '18 at 14:18

Altivo

490
6
13

score 1 · Answer 8 · answered Feb 17 '16 at 15:05

1

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.

answered Feb 17 '16 at 15:05

Ryan_S

304
3
10

score 0 · Answer 9 · answered Jun 07 '10 at 00:20

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.

Unfortunately, installing Visual Studio on this server is probably out of the question. Thanks for the info, though. — Tim Long, Jun 07 '10 at 00:28

MSBuild on CI Server can't find AL.exe

9 Answers9

Linked