Task failed because AL.exe was not found,

Question

I'm getting the following error when compiling my project:

Task failed because "AL.exe" was not found, or the correct Microsoft Windows SDK is not installed. The task is looking for "AL.exe" in the "bin" subdirectory beneath the location specified in the InstallationFolder value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A. You may be able to solve the problem by doing one of the following:

1. Install the Microsoft Windows SDK for Windows Server 2008 and .NET Framework 3.5.
2. Install Visual Studio 2008.
3. Manually set the above registry key to the correct location.
4. Pass the correct location into the "ToolPath" parameter of the task.

This error comes when I'm adding resource files to my folder in my UnitTest project. These resource files aren't directly used by my program for localization, they're just like normal files. I need them for unit testing some logic inside my program which loads these resource files using the ResXResourceReader.

Can someone explain me why this error comes up??

Edit: Installing the Windows SDK solved the issue, as also described in the error. But I'd still like to know why the error appeared. I doesn't make sense to me.

Answer 1

You are getting this error because you are building a 3.5 project that uses an assembly manifest, but do not have the 3.5 tools installed. (Hopefully, someone can provide more information.)

I strongly recommend installing Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1 and avoid the hacks, especially when you only need to install the tools, and be sure to check out the release notes for AL.exe information. (This SDK is the recommended installation for 3.5 due to a security update fix.)

The "Release Notes" for the SDK indicates that ALTOOLPATH is set by Visual Studio 2005, which might explain why some user have problems building. This is a guess on my part.

Using SysInternals' Process Monitor, when building a 3.5 project, Visual Studio 2008 looks in the %SystemRoot%\Microsoft.NET\Framework\v3.5 folder for the Assembly Linker (AL.exe). Failing to find AL there, it will use the location specified in the specific v6.0A registry setting. (Note that v6.0A is not for .NET 3.5.) Therefore, install the proper software and do not hack. :O)

The question I have is the Assembly Linker different between 2.0, 3.0, and 3.5?

---

Windows SDK for Windows Server 2008 and .NET Framework 3.5

Installing the newly released Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1 instead of this release is recommended. If you do go ahead and install this SDK after VS2008 SP1, please ensure the patch described in Knowledge Base 974479 is applied. See Overview section for more information.

Answer 2

Unload your project and then edit your .csproj file you will see an import Task

<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" /> 

MSBuildBinPath = "C:\WINDOWS\Microsoft.NET\Framework\v3.5" if ur project is targetting .Net 3.5

then go to

C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.CSharp.targets file

open this file in notepad and search for AL task and you will get something like this

 <AL AlgorithmId="$(Satellite_AlgorithmId)"
            BaseAddress="$(Satellite_BaseAddress)"
            CompanyName="$(Satellite_CompanyName)"
            Configuration="$(Satellite_Configuration)"
            Copyright="$(Satellite_Copyright)"
            Culture="%(Culture)"
            DelaySign="$(DelaySign)"
            Description="$(Satellite_Description)"
            EmbedResources="@(_SatelliteAssemblyResourceInputs)"
            EvidenceFile="$(Satellite_EvidenceFile)"
            FileVersion="$(Satellite_FileVersion)"
            Flags="$(Satellite_Flags)"
            GenerateFullPaths="$(Satellite_GenerateFullPaths)"
            KeyContainer="$(KeyContainerName)"
            KeyFile="$(KeyOriginatorFile)"
            LinkResources="@(Satellite_LinkResource)"
            MainEntryPoint="$(Satellite_MainEntryPoint)"
            OutputAssembly="$(IntermediateOutputPath)%(Culture)\$(TargetName).resources.dll"
            Platform="$(PlatformTarget)"
            ProductName="$(Satellite_ProductName)"
            ProductVersion="$(Satellite_ProductVersion)"
            ResponseFiles="@(AlResponseFile)"
            SourceModules="@(Satellite_SourceModule)"
            TargetType="$(Satellite_TargetType)"
            TemplateFile="$(IntermediateOutputPath)$(TargetName)$(TargetExt)"
            Title="$(Satellite_Title)"
            ****ToolPath="C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727"****
            Trademark="$(Satellite_Trademark)"
            Version="$(Satellite_Version)"
            Win32Icon="$(Satellite_Win32Icon)"
            Win32Resource="$(Satellite_Win32Resource)">

            <Output TaskParameter="OutputAssembly" ItemName="FileWrites"/>

        </AL>

Note that I chnaged the ToolPath to the location where AL exist on my machine.

By default it uses $(AlToolPath), Not sure what is the value of this property but i am sure if you are getting this error it is not pointing to correct location

So in simple words AL task can't find AL.exe and when you edit it and provide it ToolPath value you help him to locate it.

Hope this explains you why you are getting this error message.

Answer 3

I did the same as dcadenas and just copied the SDKs\7.0A folder from a dev machine and exported the v7.0A registry settings from a dev box to the build server. This worked out great as I then did not need to install VS 2010 on the build server. Thanks.

Answer 4

I had the same error, which came from adding resource files to a local folder and changing the build action to "Embedded Resources" (resources -> properties) while modifying localization resources to MVC3 from webforms see MVC2 Globalization. The exact error is caused by the Resources.lang.resx containing a "." in the name (combined with "emdedded resources").

Previously the application compiled and ran fine while using global resources with a build action of "Content" (App_GlobalResources).

The solution was similar to @vicky kole's above but I thought it's still worth mentioning due a few differences and the exact cause of the al.exe error in a previously working project.

After some troubleshooting I installed the Windows 7 & ASP.NET 4 SDK, and located al.exe in the C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x64 folder with a search.

I then searched the C:\WINDOWS\Microsoft.NET\Framework\*NEWEST VERSION*\*.targets until I found the same AL node as @vicky kole above. It was in a different file called Microsoft.Common.targets. I took the path from the newly installed SDK C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x64 in my case and put it in the ToolPath as vicky did and restarted visual studio.

<AL AlgorithmId="$(Satellite_AlgorithmId)"
ToolPath="C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x64"

(this could be a comment to her post as it's really similar to her situation)

Answer 5

No need to install VS2010 on the Build servers.

Export the "v7.0A" key from your dev box, import it into the build server's registry. Just make sure you rename any "Program Files (x86)" to just "Program Files" depending on what version of windows servers you are running.