Ghost MSBuild.exe in VS11 when using custom task - by SimonCropp

Status : 

 


58
0
Sign in
to vote
ID 731094 Comments
Status Closed Workarounds
Type Bug Repros 9
Opened 3/14/2012 3:19:45 AM
Access Restriction Public

Description

When you use a custom task in VS11 you end up with a ghost msbuild.exe that does not close when you close VS
Sign in to post a comment.
Posted by Sean-Feldman on 3/5/2015 at 8:04 AM
I'm affected as well. Running on VS2013 Update 4.
Posted by Microsoft on 1/24/2013 at 11:08 AM
Hello Simon. We have marked this bug as fixed because VS Update 1 has resolved the issue that caused MSBuild.exe nodes to persist after closing Visual Studio. We understand that reusing MSBuild nodes has certain ramifications as it caches task assemblies across multiple projects. However, these ramifications have been weighed against the performance gained across the most common cases. There are two workarounds for this caching issue. Either set the environment variable MSBUILDDISABLENODEREUSE=1 which will isolate the MSBuild nodes between projects as it was in VS2010, or strong name sign the task assemblies to differentiate unique versions. If you would like to further discuss this other issue, please open a new connect bug and reply with the ID so we can ensure it is routed appropriately. Please understand, however, that given there are several workarounds for this issue, it is unlikely to be fixed in upcoming versions of Visual Studio.
Posted by SimonCropp on 1/22/2013 at 5:37 PM
Reopened. For the 3rd time

Please create a new bug for the new, more serious, issue you have created in your attempt to fix this issue. Then add a link to that new issue here.

Otherwise leave this issue open
Posted by Microsoft on 1/22/2013 at 5:22 PM
Hello and thank you for your valuable feedback. We are closing this bug as fixed because the original issue as opened has been fixed, as you confirmed, in VS Update 1. We understand that the other issue, caused by reuse of the MSBuild AppDomain, is a pain point and have copied it to our internal backlog. Though we will not have a chance to address this issue in Visual Studio 2012, we will consider this feedback when planning for future versions of Visual Studio. Investments in this area will be weighed against the impact of other customer reported issues.
Posted by SimonCropp on 11/15/2012 at 7:09 PM

It seems the problem still exists. I can repro is with a slight modification to my blog post

http://simoncropp.com/flawed-assembly-caching-in-vs11-beta


My previous scenario prior to Update 1 was
1. Open and Build Solution 1
2. Close Visual Studio
3. Open and Build Solution 2

After Update 1 i can reproduce it with
1. Open and Build Solution 1
2. Open and Build Solution 2

So it seems Update 1 has fixed the scenario where the MSBuild.exe AppDomain was being re-used when closing and opening solutions. But it has create a much more serious bug of sharing the MSBuild.exe AppDomain across running instance of VS

Can I please get a response from someone regarding this bug. And please re-open the connect issue.
Posted by SimonCropp on 10/13/2012 at 6:45 PM
I have re-opened this again because, for the third time, it has been closed without adequate information as to how/when it will actually be fixed . So again... Please do not "mark as fixed" with no comments and no "version fixed in".
Posted by SimonCropp on 9/8/2012 at 1:35 AM
Please do not "mark as fixed" with no comments and no "version fixed in".
Posted by Microsoft on 5/23/2012 at 4:13 PM
Thank you for your feedback. We understand this is a pain point. We discussed possible fixes internally and all of the fixes are high risk/high cost. At this point in the VS11 cycle, we unfortunately cannot afford to take such risk. We will move this bug in our post-VS11 backlog to consider fixing in the future. We appreciate the severity of this issue.
Posted by Jamie da Silva on 3/26/2012 at 1:10 PM
Simon makes some great arguments. As an idea maybe there could be a option added to msbuild to shutdown any outstanding nodes. This could be associated with a key that is passed to msbuild originally so nodes can be reused within a particular context and then cleaned up when done. This would also solve issues like this: http://stackoverflow.com/questions/3919892/msbuild-exe-staying-open-locking-files. It seems a shame to have to disable node reuse within a build to get predictable behavior outside the build.
Posted by Red Knight on 3/26/2012 at 7:22 AM
After reading the details I concur with SimonCropp. Any by-design feature should ensure correct/expected behavior. This "feature" does not.
Posted by SimonCropp on 3/26/2012 at 5:54 AM
I outlined my issues with this "feature" here http://simoncropp.com/flawed-assembly-caching-in-vs11-beta

Please consider re-opening this as a bug.
Posted by Microsoft on 3/14/2012 at 11:53 PM
Hi Simon,
Thanks for the report. This is by design, since MSBuild 3.5. The child processes persist until 15 minutes has passed without use (ie without a build). This gives some performance gains in some cases. It's quite possible to disable it. If you're using msbuild.exe, set /nodereuse:false. If you're using Visual Studio, set an environment variable MSBUILDDISABLENODEREUSE=1. Everything will work functionally the same.

Dan
Posted by MS-Moderator07 [Feedback Moderator] on 3/14/2012 at 8:11 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by MS-Moderator01 on 3/14/2012 at 3:52 AM
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)