CODEWITHSUNDEEP
visual-studiodebugging
mrblah
mrblah

Reputation: 103477

breakpoint will not currently be hit, why not?

Sometimes I get the message that the breakpoint will not be hit, and no symbols will be loaded.

The red icon in vs.net changes color, and the debug mode just doesn't work.

what is the reason for this?

Upvotes: 24

Views: 49047

Answers (15)

Satish Patil
Satish Patil

Reputation: 13

In my case, I tried the solution below, and it worked.

  1. Close browser instances that are already open for localhost.
  2. Make sure that IISExpress is running and pointing to the correct port.
  3. Select your default browser from Visual Studio.
  4. Run localhost and attach the debugger from Visual Studio ( select Managed IIS express process only to attach debugger).

Upvotes: 0

tal
tal

Reputation: 409

  1. for manage code only - theres a good answer for this problem on the following site: Link
  2. for native + managed code - in the startup solution properties-> Debug tab make sure that "enable unmanaged code debugging" check box is checked

Upvotes: 5

Wasim
Wasim

Reputation: 724

For me it was giving this because I haven't started the relevant project at start of application , it worked after I added project run on start

Upvotes: 0

RadicalGratitude
RadicalGratitude

Reputation: 415

To fix this I had to re-create the virtual directory. I'm using Asp.Net 4.7 Framework and IIS Express. Went to Web project > property page > Web tab > clicked the "Create Virtual Directory" button next to Project Url textbox.

enter image description here

I forgot I had clicked this button in my "Main" branch, but then had switched to my "Sprint" branch. It kept running the "Main" code until I clicked "Create Virtual Directory" on my "Sprint" branch.

Upvotes: 0

JustBeingHelpful
JustBeingHelpful

Reputation: 18980

From Visual studio debugging issue with files of the same name by Philip Carney

Do each bullet in the link below ONE AT A TIME, but repeat my steps below with each one you try.

  1. Stop debugging (press red square icon) in Visual Studio

  2. Clean Solution

  3. Build Solution

  4. Tools > Attach to Process (or start with debugging)

  5. Start the program that you're attaching to, and run it such that your code will get hit

    • If attaching to nunit.exe, then open NUnit and run a test so your breakpoint will be hit

    • If attaching to w3wp.exe (IIS site), then open your site in the browser and go to the page that will hit your breakpoint

Upvotes: 8

Muhammad Bilal
Muhammad Bilal

Reputation: 107

I have tested with both deployed application and service, what I have found out that If the deployed code is different than a code in visual studio then breakpoint will not hit. Even small changes will affect and the breakpoint will not hit. So, It is better to debug the same version which is there on vs code and also in deploy application or service.

Upvotes: 0

martial
martial

Reputation: 3883

Next to the "Debug/Release" dropdown list, there is another one with "Any CPU/Configuration Manager...". Click "Configuration Manager...", and you will see some of your projects might be in Release mode. Change all of them to Debug.

Upvotes: 2

Yigit Pilevne
Yigit Pilevne

Reputation: 555

You may be running your project in Release mode. If so, then switch to Debug mode

enter image description here

Upvotes: 22

eaglei22
eaglei22

Reputation: 2831

I had the same problem. Which I know is normally if the build versions are different, and something isn't matching up. I cleaned my project, rebuilt it, and then deployed and that got everything back in-sync.

Upvotes: 1

abshar
abshar

Reputation: 475

I resolved this problem by selecting Automatic:Native Code for the "Attach to" field in "Attach To Process" formenter image description here

Upvotes: 1

daveomcd
daveomcd

Reputation: 6555

After trying several suggested fixes for this I did the following to get it working.

  1. Right Clicked my Project in the Solution Explorer and selected "Properties".
  2. Went to the "Web" section and made sure "Start Action" was set to "Current Page".

Spent 3 1/2 hours on that... I'm going to go get a drink now.

Upvotes: 4

Phil Helix
Phil Helix

Reputation: 3723

I do not like to play with knives but the only thing that worked for me involved editing the .csproj file itself. So, unload the project file, edit it by cutting and pasting the three asp.net files so that they are together in the ItemGroup. However, sometimes it is necessary to go further as explained here: http://carnotaurus.tumblr.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same - Also, I give a list of other proposed solutions that did not work for me. I hope it helps.

Upvotes: 0

Marc Bernier
Marc Bernier

Reputation: 2996

What does it say when you hover the mouse over the disabled breakpoint? It will usually tell you the problem. My favorite is the old 'source code is out of date', especially when I'm debugging a DLL. Another favorite is when the file you're looking at isn't the one you're debugging (a copy in another folder?). If it's a case where you can breakpoint a caller routine, but not the callee, stepping into the callee will force VS to open the 'proper' source file and you'll be able to set breakpoints. Confusing, I usually swear at VS at this point, it seems to help.

Upvotes: 2

Aaron Daniels
Aaron Daniels

Reputation: 9664

This can also happen if the debugger is not attached to the process for whatever reason. If it's the case, you can always go to Debug - Attach to Process... and choose the right process. Your breakpoints should return to normal once VS determines it can hit them.

Upvotes: 1

Adriaan Stander
Adriaan Stander

Reputation: 166326

This can happen if the symbol fiels are different from the assembly (remote debugging), or when there is no "direct path", so the assembly hasent been load, but might be loaded using reflection and loading of the required assembly at run time.

Upvotes: 1

Related Questions