开发者

Visual Studio 2010 will attempt to start build after detaching from remote debugger

开发者 https://www.devze.com 2023-02-22 00:16 出处:网络
I keep having intermittent issues with visual studio 2010: I\'m working on a rather large solution (200+ projects), so the whole solution takes a long time to build even with a little change.

I keep having intermittent issues with visual studio 2010: I'm working on a rather large solution (200+ projects), so the whole solution takes a long time to build even with a little change.

I often need to debug processes on remote machines.

What I noticed is that visual studio would often appear hung on detach or terminate remote process. On closer examination, it appears that immediately afte开发者_C百科r debugger disconnects, VS will start to build solution, and it is not possible to cancel the build by pressing Ctrl+Break, in fact no menus work at all until the build finishes or fails, and with large solution it takes a long time. One way I found which would fix this issue is killing the MSBuild.exe processes, spawned by VS, which would fail the build.

Have anyone seen this behavior? Is there any fix? Very annoying

EDIT: This is how the process explorer looks after disconnect from debugger: http://vvcap.net/db/oz1NMoyXnWWlQp8mWaRY.htp


This would happen when you edit code while a breakpoint is active. After the debugging session ends, VS automatically rebuilds the solution to incorporate the changes into the binaries, not just in memory. This does tend to make VS a bit catatonic, I think it tries to prevent you from doing anything that would interrupt that operation. This normally doesn't take more than a couple of seconds but I have no idea what might happen in such a large solution. Disabling E+C is probably not one of the workarounds you'd contemplate if you are used to being able to edit code while debugging.

Having solutions with 200 projects does tend to test the limits of endurance. Do try to whittle it down to a core set of projects, chucking out the ones that shouldn't change because doing so would break too much code in higher layers. Or just create another solution and include only the projects you want to test. It doesn't otherwise affect the debugging session, you can still debug code from such projects as normal. Without E+C of course.


Such amount of projects in a solution file can take a LOT of time to build. I can't (myself) imagine) the worries before pressing ctrl+b (know that takes 30 seconds of my working hours). I would tell my boss that we are in badly need of insert a 40 hour delay because of refactoring the projects into maintanable & compilable parts (sharing same dll into each library per purpose/layer). If the delays is about pure project redefining or just splitting out the solution into several projects fully depends on your work. At least the parts where I am expecting problems and are about to change,

0

精彩评论

暂无评论...
验证码 换一张
取 消