{"id":1873,"date":"2010-07-08T16:52:55","date_gmt":"2010-07-08T16:52:55","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/visualstudio\/2010\/07\/08\/debugging-msbuild-script-with-visual-studio-2\/"},"modified":"2022-05-18T04:37:10","modified_gmt":"2022-05-18T11:37:10","slug":"debugging-msbuild-script-with-visual-studio-2","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/visualstudio\/debugging-msbuild-script-with-visual-studio-2\/","title":{"rendered":"Debugging MSBuild script with Visual Studio (2)"},"content":{"rendered":"

In my previous post<\/a>, I showed how to enable the hidden Visual Studio debugger for MSBuild script, and demonstrated it by stepping through the evaluation of a C# project. In this post, I’ll keep debugging into the actual build of that project.<\/p>\n

Note that this blog is rather narrow, so some of the screenshots may be hard to see \u2013 you can click on them to see the full size version.<\/p>\n

Starting from where we left off last post, I’ll set a breakpoint in Microsoft.CSharp.targets on the <Csc> task tag. That’s where the compiler will run. Then hit F5 to run to it.<\/p>\n

\"image\"<\/a>  <\/p>\n

Ideally, I’d be able to set a breakpoint on the enclosing <Target> tag, but unfortunately there’s a bug: you can’t. As a workaround you could inspect the values of a target’s attributes when you get to the first tag in the body of that target. If the target’s condition is false, or if its inputs and outputs are up to date so that it skips, it’s not so simple. You’d have to work around this by stepping up to the target before. <\/p>\n

I’d like to be able to evaluate the condition on the task there, but because it’s batchable<\/a> it could have multiple results: the EvaluateCondition delegate I used before won’t accept it. If this was a parameter on the task, I’d probably step into the task’s code itself to see the value. Since it’s a condition, I’d probably look through the metadata on the item list directly, or query the object model in some way.<\/p>\n

Something like the value of Sources is easy to evaluate here, though:<\/p>\n

\"image\"<\/a> <\/p>\n

Now I want to step into the task implementation.<\/p>\n

You might think that at this point, you can simply Step In (F11). However, you can’t \u2013 it happens that MSBuild will run this task on a different thread. To know to jump threads properly here, the debugger has to support what they call "causality" for this kind of debugging, and since it doesn’t know anything about MSBuild, it doesn’t. <\/p>\n

It’s easy to get the job done though \u2013 set a breakpoint in the task and run until it’s hit.<\/p>\n

I have the source code for the Csc task, so I set a breakpoint here on the setter of the WarningLevel property, and did Continue (F5). I can see the task is getting "4" as the value of that property here. I can debug this code just like any other C# code, stepping through methods and so forth. <\/p>\n

\"image\"<\/a> <\/p>\n<\/p>\n

To get out to the XML, I’ll set a breakpoint in it and run \u2013 the same trick I used to get into the C#, but in reverse. Here I’m at the next tag after the task:<\/p>\n

\"image\"<\/a> <\/p>\n

I used Csc as an example here, but you’ll generally be debugging a custom task (or possibly, logger). Just make sure the assembly is not optimized: since you have Just-My-Code on, it won’t be debuggable otherwise. If you only have access to an optimized one, you can switch off Just-My-Code temporarily.<\/p>\n

There’s a CallTarget tag here: you can step into those, and like imports they’ll look like a new frame on the callstack \u2013 although unlike imports, that’s correct for their semantics.<\/p>\n

Probably the biggest limitation (bug) with the debugger right now is that you can’t see item and property changes made inside a target. For example, at this point @(_CoreCompileResourceInputs) should be empty because of the line above, but the immediate window tells me it isn’t:<\/p>\n

\"image\"<\/a> <\/p>\n

When you get past that target, you can see the changes.<\/p>\n

Scenario 2: Debugging a build with multiple projects<\/h3>\n

Typically there’s more than one project in a build. I’ve added a project reference from this project to another. I’ve put a breakpoint at the top of that project, and run to it:<\/p>\n

\"image\"<\/a> <\/p>\n

The bottom of the callstack is the point in Microsoft.Common.targets where, early in the build of WindowsFormsApplication1, it invoked WindowsFormsApplication2.<\/p>\n

In my next posts I’m going to cover<\/h5>\n<\/p>\n