Wednesday, April 30, 2008

"AL.exe" was not found

So, as I said earlier I am setting up CruiseControl.Net to begin my company's journey into Continuous Integration.  My earlier problem is not solved but I have moved on from the 2.0 build to the 3.5 build.

Now, I am not one to get frustrated easily.  I typically keep moving and document my challenges as I go. So I ran my project in CC and I got the following message:

C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets (2083,9): errorMSB3091: 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.

What is a person to do when presented with options for a solution to a problem?  Well first I did what it said. Or so I thought.  I diligently went to the msdn download center for the Windows SDK for Windows Server 2008 and .Net Framework 3.5 and installed the web installation setup.exe. (pet peeve==Why call an exe setup?  Use words to tell me what it is going to setup. ie.. WinSDK4Win2008and.NetFW3.5Setup.exe - which is what I named it.) After the install, which I thought was complete, I looked to see if it actually installed AL.exe in the said directory.

Nope.

It didn't install AL.exe at all.  Why?  I don't know.  So I thought maybe I didn't install it properly so I downloaded the iso. Mounted it to a virtual disk using UltraISO. Installed everything.  You might think it installed AL.exe in the said directory, but Nope. it did install AL.exe.  But it did it in the v6.1\bin directory.  I thought, ok it is there and the registry key mentioned is slightly different so lets try the build.

Nope.  Didn't work.

So I opened regedit and added the above key by exporting the v6.1 directory to a .reg file and editing that file to be v6.0A. using the path to the v6.1 directory. This is gonna work!

Nope.

So I was confused. What else could be the issue?  So I looked in the directory where AL.exe is and there is a file called al.exe.config.  Hmm? What could that be? I opened it up and here is what it had in it:

<?xml version ="1.0"?>
<configuration>
    <startup>
        <supportedRuntime version="v2.0.50727"/>
    </startup>
</configuration>

Well, It doesn't have an entry for version 3.0 or 3.5.  So I added it. Heehe. No it looked like this:

<?xml version ="1.0"?>
<configuration>
    <startup>
        <supportedRuntime version="v2.0.50727"/>
        <supportedRuntime version="v3.0"/>
        <supportedRuntime version="v3.5"/>
    </startup>
</configuration>

Force a build in CC and low and behold - Green!

I am not sure why Microsoft made me go through all of this but it works now!

6 comments:

  1. I tried this for a problem I was having running the MS Workflow 'WF Tools' on Codeplex and it didn't help.

    I did find another solution to the problem, which worked for me!

    http://bhaidar.net/cs/archive/2007/12/25/al-exe-not-found-solution.aspx

    ReplyDelete
  2. David, just wanted to thank you for the post... Your solution fixed the last (I hope) of my CCNET integration issues. One thing I'd like to add to anyone who might read this -- it is not necessary to install the entire contents of the 2008/3.5 SDK. You only need to install the developer tools (and not the documentation and samples) if you're trying to save space. Thanks again!

    ReplyDelete
  3. Here's how I solved 'AL.exe not found...':

    1. Look in "C:\Program Files\Microsoft SDKs\Windows\" and note the name of it's only subfolder. For me the subfolder's name was "v6.1".

    2. Open regedit and go to "C:\Program Files\Microsoft SDKs\Windows"

    3. The registry key in #2 should have only one subkey - and it's name should be the same as the subfolder in #1. Again, for me, it was "v6.1".

    Originally I had two subkeys "6.0A" and "v6.1" and the old key was read causing Visual Studio to look in a nonexistent folder and produce the error.

    HTH!

    ReplyDelete
  4. Thank you, you saved my day :)

    ReplyDelete
  5. David bro.. u rocks!!!
    i was fighting with this problem from morning..
    thanks a million.. :)

    ReplyDelete