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

New Challenge

So this Monday morning has given me a new challenge that I am looking forward to solving. I began working on moving to CruiseControl.Net and MSBuild for our CI. This is in the very early stages. I decided to use the least resistance path to setting up CruiseControl.


I setup CruiseControl (done this many times at my previous job) without incident. I edited the ccnet.config file to use perforce. I am still getting an error there but went around it by getting latest to my workspace. I'll deal with that later. Created a sample project and solution. Got CC to build it. Hurray, I'm in the clear!

Nope.

I grabbed an existing solution with about ten C++ projects, no external dependencies, and a quick build time inside visual studio. I pointed CC to it and BANG, big fat error:

C:\Projects\CCTestProj\CCTestProj.sln (,): error MSB4018: The "ResolveVCProjectOutput" task failed unexpectedly. System.ArgumentException: Illegal characters in path. at System.IO.Path.CheckInvalidPathChars(String path) at System.IO.Path.IsPathRooted(String path) at Microsoft.Build.Tasks.ResolveVCProjectOutput.ResolveUsingVCEngineObjectModel(ITaskItem projectRef, String configName, String&amp; resolvedAssemblyPath, String&amp; resolvedImportLibraryPath) at Microsoft.Build.Tasks.ResolveVCProjectOutput.Execute() at Microsoft.Build.BuildEngine.TaskEngine.ExecuteTask(ExecutionMode howToExecuteTask, Hashtable projectItemsAvailableToTask, BuildPropertyGroup projectPropertiesAvailableToTask, Boolean&amp; taskClassWasFound)
Names have been changed to protect the innocent.

I thought, Illegal characters in the path? What is this? Visual Studio builds it fine. Why is MSBuild having a problem. So I dug around some. Thought it was related to references or something like that. No path problems could be found. Nothing in the CC log or the MSBuild log was helpful

So I decided to create a new solution and slowly bring in one project at a time to see where the problem lays. I created the solution added an existing project which was the first project in the build order of the original solution. CC built it fine. I grabbed the next project. No problems. I grabbed the third project in the original solution's build order and CC built it without a problem. I was getting nowhere fast.

But then I noticed CC and MSBuild was not building the projects in order. I thought, David you forgot to set the project dependencies in Visual Studio for the solution to build in the right order. There are no direct references but I wanted it to build in the same order as the original solution just in case. So this is where we were at:

Projects build order in original solution:
P1
P2
P3
Project build order in new solution:
P1
P3
P2

So I set in visual studio that P2 depended on P1 and built in VS. Worked. I then forced a build in CC and Viola! Same error as above.

I posted this in the MS forums and waiting for a reply. I am also doing some more experimenting to further define the problem.