What do the colored shirts mean?

For those who know me and what I do when I am not at my regular 9 to 5, you know that I sometimes I work in the theater and at concerts as a stagehand (the best description of a stagehand I have ever seen is found here.)  When I lived in Rhode Island I was a member of IATSE with the now defunct local 538. When 538 was swallowed up by the ever hungry local 84 out of Hartford CT, I took an Honorable Withdrawal from 538. I did this for various reasons. I continued to work with a group closer to me, though not union.

That was years ago now, and the point of this blog is not about my history.  Move forward to 2009.  I am now in a new state with new exciting opportunities.  I hooked up with local 417 down here in Raleigh/Durham.  A great bunch of stagehands who know their stuff.  I haven’t officially joined the local yet, I am still a little upset about what happened up north, but I am sure the time will come for me to chip in and be a part of the organization again.

So.  After that lengthy intro, to my agonizingly pointless point. At my current 9 to 5 I am able to wear t-shirts and jeans, or shorts and sandals if I so desire. I frequently wear t-shirts of differing colors with various rock, country, and pop band’s logos on them.  I am asked occasionally where I get these shirts and have I attended the concerts and isn’t this band great and that concert was horrible etc.. I don’t go into a lengthy explanation of the term “SWAG” in the industry, but I do tell them that I do stagehand work on the side and we sometimes get t-shirts from the talent for the work we do.

Now, my wife hates how many t-shirts I have and I’ll admit that I probably have too many and should get rid of some of them. (not my Aerosmith ones though!)  They are “what I wear.”  They come in many different colors, but mostly black as you might imagine.  Black is the default color worn by all stagehands. They are not always black, though. 

After you go to a concert and the houselights come up, you may see many stagehands in different colored shirts.  There is a group over there in blue, a group over there in red and a group over there in green.  Each colored shirt represents a discipline. One color for Lighting, one color for Audio, Carpenters and the ever popular Pushers.  A “Pusher” is a stagehand that literally pushes boxes from where they are to where they need to be.  I am usually a “Loader” or in Lighting.  Loaders are the guys that take the boxes and load them onto the trucks during the Load-Out or unload them during the Load-In. The “Riggers” are the guys above your head, carrying span-sets and working that 1/2 ton motor that raises and lowers the lighting truss.  We wear our shirts when we work so all the touring crew can tell what discipline the house crew works in.

So “What do the colored shirts mean?” Well, they mean a great deal.

Another great CCNet applet!

Craig Sutherland has become a prolific contributor to CruiseControl.Net recently.  He has pushed the envelope and I think is making some positive changes with the structure and architecture of CruiseControl.Net.  A while ago he started down the road of creating a replacement for CCTray, a staple among CCNet users.  He was going to migrate this replacement into the actual product but got some resistance so he started his own app that will, when complete, replace CCTray in my eyes.

The application is called FastForward.Net.  It is currently in CTP but I have been using it for a few days now and it has almost completely replaced cctray.  I am using it for our build farm of 15+ servers using CCNet 1.4.4.  I am sure once we move to CCNet 1.5, this applet will be even more functional for me.

There are, as you might expect with a CTP, some issues that need to be overcome.  But, overall I am very pleased.

Great job Craig!

Great CCNet applet!

I have been looking for something that will allow me to do a force build of one of my CruiseControl.Net projects after I reformat the build drive in the middle of the night.  This would cause a rebuild of my project after I do a force sync with perforce.

I was trolling the CruiseControl.Net blogs last night and I came upon a post by Craig Sutherland.  He has created an applet for CruiseControl.Net that will allow for forcing a build from the command line.  This is exactly what I have been looking for so his post was very timely for me.

Now after I do a format of the build drive in the middle of the night, I do a force sync with perforce and then force a build of the first project which causes a rebuild of my project. Done!

Thanks Craig!

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