'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?

visual-studio debugging

Solution 1:^[1]

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

Solution 2:^[2]

for manage code only - theres a good answer for this problem on the following site: http://geekswithblogs.net/dbutscher/archive/2007/06/26/113472.aspx
for native + managed code - in the startup solution properties-> Debug tab make sure that "enable unmanaged code debugging" check box is checked

Solution 3:^[3]

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.

Stop debugging (press red square icon) in Visual Studio
Clean Solution
Build Solution
Tools > Attach to Process (or start with debugging)
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

Solution 4:^[4]

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

Right Clicked my Project in the Solution Explorer and selected "Properties".
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.

Solution 5:^[5]

I resolved this problem by selecting Automatic:Native Code for the "Attach to" field in "Attach To Process" form

Solution 6:^[6]

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.

Solution 7:^[7]

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.

Solution 8:^[8]

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.

Solution 9:^[9]

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.

Solution 10:^[10]

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.

Solution 11:^[11]

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.

Solution 12:^[12]

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.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution	Source
Solution 1	Yigit Pilevne
Solution 2
Solution 3	KyleMit
Solution 4	daveomcd
Solution 5
Solution 6	martial
Solution 7	Adriaan Stander
Solution 8
Solution 9	eaglei22
Solution 10	Marc Bernier
Solution 11
Solution 12	Muhammad Bilal

'breakpoint will not currently be hit, why not?

Solution 1:[1]

Solution 2:[2]

Solution 3:[3]

Solution 4:[4]

Solution 5:[5]

Solution 6:[6]

Solution 7:[7]

Solution 8:[8]

Solution 9:[9]

Solution 10:[10]

Solution 11:[11]

Solution 12:[12]