Builds occur on the UI thread in VS 2010 by Stephen Styrchak

Hi folks,

We have addressed this issue in the next version of Visual Studio where builds for VB and C# projects have been moved off of the UI thread. If you would like, you can preview the change by downloading the Visual Studio Developer preview from http://msdn.microsoft.com/en-us/vstudio/hh127353 .

However, I also realize that this doesn't improve your current experience with VS2010. For VS2010 and previous releases, I'd highly recommend reading through this blog post by Scott Hanselman, where he discusses a mechanism for running builds out of the VS process, and parallelizing the builds along the way to improve your build's performance:
http://www.hanselman.com/blog/FasterBuildsWithMSBuildUsingParallelBuildsAndMulticoreCPUs.aspx


We appreciate the feedback and your patience with our reply on this request.

Thanks,
Nathan Halstead
Visual Studio Program Manager

@Rami_: As far as I can tell this only fixes the problem with post-builds. I'm currently on a project with buildtimes around 4-5 minutes (mostly due to the total incompetence that the build system in VS2010 was made with) and like Eric pointed out, it is extremely annoying that the entire UI is unresponsive.

I would hope Microsoft could send out a hotfix, since this is very counterproductive when working with larger projects. I'm still trying to comprehend why this was not fixed in SP1...

See the workarounds tab for a work-around using a custom msbuild task.

I am wondering if using an msbuild <exec> task (or a custom msbuild task that behaves like <exec>) for example can be used to work-around this issue??

Fix this, it's not only a bug it's a regression...

I have a project with both a HUGE XNA build process AND a large post build step in my release scenario. Not only does it appear to hang there is no way to break into the build if I notice something is wrong.

Its very hard to see the progress as well so you know everything is happening.

It seems likely that the output from the project could (and should) be processed by a worker thread that monitors the output stream of the worker build via ProcessStartInfo.RedirectStandardOutput.. which it must already be doing in order to put it in the output window in the first place. There is no good reason for the Visual Studio UI to do a blocking read on the stream and remain unresponsive until the worker processes are completed. We have many time consuming external build tasks and this is an ongoing source of lost productivity for us that I hope can be corrected soon.
Thanks

I'm disappointed that after I listed six scenarios in which this bug could be reproduced, this bug was closed immediately because ONE of the six scenarios was external. What about the other five? The point of the list was to illustrate how common this problem can be.

I've now attached a solution that reproduces the problem quite clearly and uses only C# console application projects. One of the projects has a post-build event to simulate a long-running build task, which was one of the repro scenarios I listed in the first place.

Unfortunately, we only accept feedback on Visual Studio & .Net Framework and related technologies through this site. For issues related to XNA, we advise contacting the XNA team through the XNA Connect Site: https://connect.microsoft.com/site/sitehome.aspx?SiteID=226

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)