How avoid new instance of Visual Studio when hit debugger statement in javascript

574 views Asked by At

When running an asp.net web site in Visual Studio 2017 on my local host, using IE 11, and debugging javascript, Visual Studio has a very convenient feature where we can put the statement "debugger;" in a javascript file, and when that statement is hit it is like hitting a normal breakpoint in Visual Studio. One can then step through the javascript code in Visual Studio.

Sometimes VS automatically uses the existing instance of Visual Studio (the instance I am using to run the web site) to step through the javascript. This is very convenient, and I would like this to happen every time.

However, sometimes I see a prompt where VS forces me to select a new instance of Visual Studio. The prompt looks like this:

enter image description here

I want to stress, there is not an unhandled exception in my javascript code. This JIT prompt is occurring solely because of the "debugger;" statement. When I go through the rigmarole of opening a new instance of VS it brings me to the "debugger;" statement and I merrily step through my javascript.

Disabling JIT debugging in Visual Studio 2017 does not fix this issue; with JIT disabled I still [sometimes] get the JIT prompt, the sole difference is that the prompt does not list VS 2017 as an option.

There does not seem to be any rhyme or reason: sometimes it automatically uses the existing instance, sometimes it throws this prompt. It will treat the exact same javascript differently, sometimes debugging it in the already-open VS, sometimes forcing me to open a new instance.

I'd like to avoid the prompt and always use the existing instance of Visual Studio, because it is faster than waiting for a new instance of VS to open and because the debugging experience is superior (e.g., I can hover over variables and see there value if I use the existing instance, whereas with a new instance I must open a watch window).

Is there any way to force VS to always use the existing instance?

1

There are 1 answers

0
Dmitry Babich On

I ran into the same problem in VS 2019 after a while. It looks like VS have this issue often. The solution is: Debug -> Attach to Process (Ctrl+Alt+P), select running process. It is harder, but allows to use the same instance of VS, and definitely faster then the new instance. After process ends, keep current VS window opened, and when you are ready to debug the same process again, hit Shift+Alt+P to reattach it.