Msbuild question

Question

I have several long running custom build tasks. It looks Visual Studio, however, runs msbuild tasks on the UI thread, which was causing the IDE to hang.

I did a little bit of searching on google, and the best I could find were some bugs reports with the response "oh yeah, that's a problem, we'll maybe fix it later".

http://connect.microsoft.com/VisualStudio/feedback/details/670873/visual-studio-ui-freezes-during-long-msbuild-task

http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/3289eb7d-7989-4350-8c43-02bf9913edbd/.

So, I decided to fix it for my custom tasks by:

1. Detecting when they are running inside of Visual Studio.
2. Running the tasks on a background thread if they are
3. Adding a "MsgWaitForMultipleHandles / Custom message pump" to the UI thread to keep the UI responsive while things run.

This seems to work. I can now run my builds without the IDE freezing.

In any case, this brought up a few questions:

1. Is this safe to do? Visual studio is a massive thing. Will I run into any re-entrancy problems if I do this? Will those re-entrancy problems cause the world to end, or can I get away with ignoring them.

2. I detect Visual Studio using the technique outlined in this post. Basically, I assign the value of the "BuildingInsideVisualStudio" property to a property on the task, which I check in my Execute() method. If it's true, then I use the multi-threaded behaviour, otherwise I just use sequential behaviour. This, however, requires each target using the task to put extra goo into the msbuild file to avoid suckyness. Ideally I would like "not sucking" to be the normal behaviour, without special configuration. Is there any way I can detect visual studio inside my task's Execute() method? Can I read the project property in the task implementation without requiring custom edits to the XML? Can I interrogate the Host object somehow?

Thanks.

Answer 1

Try setting the environment variable MSBuildNoInProcNode to 1 and then launch the IDE. This will force IDE build requests to child nodes. Make note that this is not a fully tested scenario so there may be some unexpected behavior, but it may be an alternative for getting the result you want without having to alter your project files or all of your custom tasks.