views:

373

answers:

4

Hi,

We use MSBuild quite extensively as part of our continuous integration process, and whilst it is incredibly powerful and we can do practically all of our build, test and deployment within it (utilising some custom tasks) - we've found that debugging it using tags is a pain and cannot always provide us with enough information.

I've found: http://www.wintellect.com/CS/blogs/jrobbins/archive/2007/12/03/msbuild-debuggers.aspx, but unfortunately the project seems to have disappeared from Codeplex.

Does anyone have any idea if there is something similar to this available or if there is another way/technique that can be used?

Thanks.

+3  A: 

I use the /v:diagnostic command-line switch. MSBuild spits out some pretty verbose output. You can also spit the verbose output to a log file instead of the console, using the /fl[n] command line switch, and then use the /flp[n] (filelogparameter) switch to specify the verbosity level, e.g., /flp:Verbosity=diagnostic;LogFile=latest_diagnostic.log

You have to design your build scripts from the start to make troubleshooting easier. Do things like:

Make each target as granular as possible, so you can call each target individually. This helps make the debugging process much quicker.

Make sure your tasks inherit from the Microsoft.Build.Utilities.Task class. It exposes a Log property that has way too many logging functions. I typically err on the side of caution use the LogMessage(MessageImportance,string,params object[]). My debugging messages get a message importance of MessageImportance.Low so they only appear when the verbosity mode is diagnostic.

Use System.Diagnostics.Trace.WriteLine for outputting messages that are are too low-level to log. I use DebugView to look at those messages.

Lastly, try not to do really complicated things in the MSBuild script itself. MSBuild excels at managing dependencies, lists of files, and running tasks. Anything more complicated or advanced should be moved to custom tasks written in your .NET language of choice. This has the added benefit of making things much easier to debug. When you've got your logic in code, you can use System.Diagnostics.Debugger.Launch() method, which will allow you to attach MSBuild to the debugger in a running instance of Visual Studio (hopefully one that has your custom task already loaded).

Good luck!

splattered bits
Thanks, good advice.
Kieran Benton
+1  A: 

You could also have a look at the excellent commercial app (with 14 day trial) MSBuild Sidekick at Attrice Corp to debug your MSBuild-script.

Bart Janson
A: 

Well if you're using custom tasks, you can utilize this approach: How To: Debug a custom MSBuild task using Visual Studio

Bolek Tekielski
+1  A: 

It's worth looking at the undocumented debugger in VS 2010 also.

Rock Hymas