For some reason when I press F10 to do a regular build of my project, it builds then launches with a breakpoint/arrow thing on the first curly bracket of my Main function.
What is causing this? It only happens every other time I build and it's quite annoying.
F10 is the "Step Over" debug command. The fact that it's being built is a side effect of the editor tracking changes that you've made since the last time the project was run. So it's doing exactly what you've asked - Debug the project and step over the first instruction.
The default code to build the project is Ctr+Shift+B.
Related
I have a .Net web project that I publish and then attach VS to w3wp.exe for debugging. I place breakpoints, load the specific web page being modified, and debug... over and over. This works fine for a while but then it just quits hitting the breakpoints and gives the error: "breakpoint cannot currently be hit, no symbols loaded.." with a hollow circle for the breakpoint. I cannot say what causes it to stop hitting the breakpoints. I'm just coding, publishing, debugging, repeating.... then I'm not. So, I do the following:
delete all debug and release folders,
delete the obj and bin folders
rebuild the solution
restart VS 2022
restart computer
update NuGet
make sure still configured for debug build
I did have some luck deleting all the files/folders in C:\Users\stever\AppData\Local\Temp\2 with today's date. In fact, I thought it WAS the fix because it fixed the issue a number of times and I was able to debug again. However, that stopped working too.
I did all the things mentioned a number of times and finally did get it to hit the breakpoints again. This has happened a lot! It sure would be nice to know what's causing this and what I need to do in order to debug again every time it happens. Any ideas for a fool-proof fix?
After a very long period of not getting this to work, I found something that works 100% for me. When I go to debug, I select "Attach to Process", then click the [Select] button for Attach To. I deselect "Automatically determine the type of code to debug" and manually select .Net 4x or .Net Core depending on what I'm debugging. Then I select the process and debug.
If it doesn't work, I stop the debugger, click [Select], and toggle "Native". Then I attach to the process again and it works every time!
I'm trying to understand the workflow of a project, and want to instrument on each file that is called.
I've tried to use definition/reference to set breakpoint manually, but it's a huge project that it might miss something this way.
I've also used the step forward button in Visual Studio but it just jumps to the very next line, which makes it impossible to trace the entire project.
Is there something that you can jump to the next file, instead of the next line? Or is there some other tools that could help me understand the flow of the codes?
What you probably want to do is:
Step Into Code with F11
Instead of:
Step Over Code with F10
Stepping into code will move into the next method being called. Often times this is located in another file but it doesn't have to be by definition.
Further Reading:
First look at the Visual Studio Debugger
Navigate through code with the Visual Studio debugger
You can use my Runtime Flow tool to understand the workflow of a project. Though it requires some manual configuration to monitor an ASP.NET application.
So I'm trying to add some new code to a project I'm working on, but Visual studio is not cooperating at all.
The project is only hitting breakpoints on code that existed prior to this set of changes. See the screenshot below, where the top and bottom breakpoints are pre-existing code, and some new code is inside the if statement.
I have no idea where to start, I've tried a clean and rebuild, to no avail.
Solved:
Debug Menu -> Options -> Debugging -> General -> Uncheck Suppress JIT optimization on module load
I'm not sure why it decided to start acting up now(haven't had this problem for a year of work on this project), but I'm guessing the code I'm trying to debug was optimized away.
Do a Rebuild All. (I see you tried that--I listed for others to consider.)
Make sure all dependencies for the code in question are current. You might have a project reference to an assembly (DLL) that has since fallen out of sync with its PDB/source code. Be sure all references point to currently compiled code.
I've sometimes seen this happen and an exit/restart of Visual Studio (all instances, just to be safe) works.
If any of these ideas work, please let us know which one did.
I went through the same issue, tried everything above and the solution for me was to do: Debug > Delete all breakpoints to start fresh.
Working on an old ASP.Net project using VB. I am using VS2012.
The debugger does not handle my breakpoints for a specific class (no prob with other classes so far).
When I run the app without having changed the file, its breakpoints are correctly hit. If I change anything into this file (even adding a \n character), the next time I run the app, its breakpoints are not hit anymore and I can read under the breakpoint the usual warning saying that "breakpoints will not be hit because the source code is different".
How can I have the debugger to accept my changes into this file? Why is it only causing trouble with this specific file?
I tried to remove my ASP temporary files as suggested in other similar posts. Did not help.
Rebuilding does not help either.
Thx in advance
Solution 1: Right click on the break point->Location->Allow the source code to be different from the original version(Tick the check box).
Solution 2: If the above solution doesn't work goto Debug->Attach to process, then attach the port/ service in which your current web project runs.
Hope this helps.
I would make sure that you currently have the Configuration Manager set to "Build" the ASP.NET project that you're making changes in. This is found under Build -> Configuration Manager.
Then rebuild the solution/project.
I am having two issues with the debugger using visual studio version 9.0.30729.1 using .net 3.1
Issue one - I hit a breakpoint, and F10, F11 do not move me to the next instruction. If I repeatedly press F10 I will eventually step to the next instruction. I can place another breakpoint further down in the code and do an F5 to get to the next breakpoint - but I miss the ability to step.
Issue two - I hit my first breakpoint, do an F5 or F10 and the program continues without stopping.
These issues seem to occur semi randomly. Sometimes they clean themselves up if I shut down visual studio and reboot my computer - but not always. This does not occur as often in my unit tests as with the GUI application.
Any ideas will be appreciated.
Do you have a great deal of threads in the program? Could be Thread 1 breaks, you step, thread 2 breaks at the same point that thread 1 just broke at
Make sure the source code hasn't changed after you've started a debugger...
Just for giggles, try turning off just my code. Uncheck the "just my code ..." option under (Tools -> Options -> Debugger -> General)
JMC can cause odd behavior in scenarios you wouldn't necessarily expect.
Make sure your .pdb files are current, otherwise the source you're debugging and the source you're running might not match.
Try cleaning up your solution directory by deleting (renaming) all files generated by Visual Studio (*.ncb, *.suo, obj/, bin/, and maybe some more).