Have you ever had one of those ideas pop in your head that makes you feel stupid and brilliant at the same time? I had just such a situation the other day when I was working to debug some custom tasks I'd written. The tasks were fairly simple - checking out and back in some assemblies that had just been compiled during a Team Build.
I followed the MSDN documentation for creating a custom task and used the TFS SDK to perform the necessary actions to create pending edits and check in the changes. I fired up MSBuild and ran the build locally after deploying my assembly to the appropriate folder and identifying the task in my build script. Of course, things didn't quite go right as the log file showed. Thinking how easy this was going to be to fix, I set a breakpoint in the first line of the Execute override and anticipated the excitement of seeing the debugger spring to life.
I was running MSBuild at the command prompt and passing in all the parameters that I needed to run the script. I switched over to the command prompt, started MSBuild, then switched back to Studio to attach to the process. Needless, to say this wasn't working. Had I been as bright as I could have been I would have found this article from 2005!!!! and saved myself some heartburn. Alas, I didn't feed the Google monster just the right words and all I got in return were bunny trails.
Left to my own devices I thought if only I had time to attach to the MSBuild process before my task ran I would be able to catch the breakpoint. Well, I do know how to slow something down so I decided to create a new custom task for pausing the build allowing me enough time to attach to the process and begin the debug prior to the custom task completing. I came up with the following:
public class Pause : Task
{
public Pause() { }
private int _milliseconds;
[Required]
public int Milliseconds
{
get { return _milliseconds; }
set { _milliseconds = value; }
}
public override bool Execute()
{
if (_milliseconds > 0)
{
Thread.Sleep(_milliseconds);
}
return true;
}
}
I registered the task and called it from my build script right before the custom task I was trying to debug:
<Target Name="BeforeCompile">
<Pause Milliseconds="20000" />
<Checkout CheckoutItems="@(SharedAssembliesPathsToUpdate)" />
</Target>
Now I had adequate time to get to the debugger and find my boneheaded mistakes. Ended up being an easy change and then things worked great.
Ever the optimist, I commented out the pause task execution and checked in my TFSBuild.proj file so I could run the build on the build machine. I kicked off the Team Build Type in Team Explorer and kaput. It died before it really began.
Fortunately, I had VS2005 loaded on the build machine so I fired it up, uncommented my pause task invocation, checked it back in to TFS, kicked off the build, attached to the MSBuild.exe process that the Team Build Service started and hit my breakpoint. The problem ended up being related to the Team Build temporary workspace and some incorrect assumptions on my part about how it was created and how the mappings would work. Once I got that figured out everything ran as expected.
Is this solution elegant? Probably not. But it is simple and occasionally simplicity is elegant in its own right.
P.S. Don't forget to remove any calls to the pause task as this has the obvious side effect of slowing down your builds!