Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Can't start debugger in VS2012 RC

Tags:

Configuration:

  • Windows 7, 64 bit
  • Microsoft Visual Studio Professional 2012 RC Version 11.0.50522.1 RCREL
  • Running VS in administrator mode
  • The VS solution contains a web application, with target: .NET Framework 4.

When I press F5, the solution builds... and nothing else happens.

  • Happens with both IIS or the VS Dev Server.
  • Happens with Platform Target of "Any CPU" or "x86"

If instead, I use the Debug / Attach to Process... menu, after a few seconds, I get:

  • "Debugger is Busy" - Debugger is performing a remote operation that is taking longer than expected. This dialog stay until I click "Terminate" and confirm it.
  • Then this dialog appears: "Microsoft Visual Studio" "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named [COMPUTER NAME]. The network connection to the Visual Studio Remote Debugger has been closed."
  • After clicking OK, the 'normal' "Attach to Process" window finally shows up. In it, the list of "Available Processes" is empty.

Any suggestions or clues?

The main points that I wonder about:

  • Why is the list of processes empty? It is not surprising that the debugger does not work if it cannot see any processes.
  • Why is it trying to do "remote" debugging, when it is just accessing the local computer?

(Cross posted on social.msdn)

like image 279
Glen Little Avatar asked Jun 24 '12 16:06

Glen Little


2 Answers

I had the same problem in VS 2012 (not the RC, but the final release) using a VS 2010 project. It would build fine, but the debugger would not start. So, I modified the solution file:

Changed "Format Verion 11.00" to "Format Verion 12.00" And changed "# Visual Studio 2010" to "# Visual Studio 2012"

It's a workaround for now until my company upgrades its projects to VS 2012.

like image 67
Adam Avatar answered Sep 28 '22 04:09

Adam


I've got a similar setup and I'd followed all the suggestions here and on Microsoft Connect - none of which worked for me. The only thing that did work was renaming MSVSMON.EXE in the x64 folder to MSVSMON.EXE.OLD and copying in the file from the x86 folder in it's place. I'm not sure if there are any other implications in doing this but it seems to have solved the problem in my case.

like image 28
Matt B Avatar answered Sep 28 '22 03:09

Matt B