Debugging the BuildProcess

Topics: General Questions
Dec 21, 2007 at 9:01 AM
The comments in the BuildProcess.BuildStarting method suggest that you can debug the BuildProcess by using

System.Diagnostics.Debugger.Break();

But when I do, nothing happens; the build process just carries on. Am I missing something?

--
Stuart
Dec 21, 2007 at 10:12 AM
Hi Stuart,

Are you sure that the code is being executed? You should add TraceLine("Hello World") somewhere in the BuildStarting method just to be sure. Then look in the output window and the message should appear just after the help-build has started.

When I uncomment that line I get a message box during builds telling me that there was an error and that I can debug or continue (IIRC). Clicking debug attached the debugger and execution is stopped at that line. I remember this working while building both inside and outside of VS. If you're still having a problem try building in both scenarios just to be sure.

- Dave
Dec 21, 2007 at 11:21 AM

Are you sure that the code is being executed?

Indeed I am, I have TraceLine calles before and after the call to the debugger and the output appears in the Output window.
Dec 21, 2007 at 11:27 AM
This is the code I have in BuildProcess...
public override void BuildStarting(BuildContext context) {
// Uncomment the following line to break into the debugger:
TraceLine("========= BEFORE DEBUGGER CALL ============");
System.Diagnostics.Debugger.Break();
TraceLine("========= AFTER DEBUGGER CALL ============");
buildStart = DateTime.Now;
}

and this is the result ...

Doc.Templates -> C:\Documents and Settings\stuarth\My Documents\Visual Studio 2005\Projects\Docs\Doc.Templates\bin\Debug\Doc.Templates.dll

Starting help build for Doc.Templates...
========= BEFORE DEBUGGER CALL ============
========= AFTER DEBUGGER CALL ============
Preparing target directory...
Merging xml documentation for QubeControls.Templates.Net2.dll...
Building documentation for Doc.Templates...

No errors, nothing pops up.

--
Stuart
Dec 21, 2007 at 12:42 PM
Hi Stuart,

Sorry, but I have no idea what could be wrong. Here's the remarks in the Debugger.Break documentation on MSDN:


If no debugger is attached, users are asked if they want to attach a debugger. If yes, the debugger is started. If a debugger is attached, the debugger is signaled with a user breakpoint event, and the debugger suspends execution of the process just as if a debugger breakpoint had been hit

This is my experience.

Have you tried building inside VS, in the DocProject External UI and on the command-line using MSBuild? I'm curious to know if this is a system-wide problem. Is this method even ignored in a simple console application (i.e., without using DocProject)?

- Dave
Dec 21, 2007 at 3:11 PM

Have you tried building inside VS, in the DocProject External UI and on the command-line using MSBuild? I'm curious to know if this is a system-wide problem. Is this method even ignored in a simple console application (i.e., without using DocProject)?


I have now, same result. I can send screenshots of the output from the external UI and/or cmdline if you want them.

I added the same line to a regular project and the debugger kicked in, as you would expect, at the right place.

--
Stuart
Dec 21, 2007 at 4:43 PM
Hi Stuart,

I just created a test DocSite and built it on the command-line, after uncommenting the Debugger.Break line in the Build Process Component. This is the command-line that I used:

msbuild DocSite36.csproj
And as expected I saw this dialog.

When you attempt this is there a debugger process started at least? (i.e., check Task Manager for some debugger executable, but make sure that it's not running before you start building.)

- Dave
Dec 24, 2007 at 9:34 AM
Dave,

I think it must be something to do with my set up as the debugger is invoked for any project that I run but not when I build a DocProject project.
Dec 26, 2007 at 9:27 PM
Hi Stuart,

I guess it could be related to settings, but I wonder if MSBuild or the secondary AppDomain is related at all. Maybe you could try creating a simple console application that:

A. calls Debugger.Break from code running in another AppDomain.
B. runs a custom MSBuild task that calls Debugger.Break.
C. does both B and A - An MSBuild task that executes code in another AppDomain, which calls Debugger.Break.

DocProject is essentially doing C.

- Dave