For some unknown reason, my visual studio adds many break marks in my code.
Some where I believe i had some in the past and some in utterly nonsense positions.
I have found nothing in the web. Dont know if thats a bug or if I am using it incorrectly.
Anyone had that before or knows how to resolve this?
I can remove them point by point until my app runs through but as soon as I start debugging, they are beeing readded. When I stop debugging, they are gone again. I was even able to capture one sample beeing added:
It litterally makes debugging impossible. I cant remove 50 break points whenever I want to debug...
Workaround #1
I have found kind of a workaround by going over Debug -> delete all Break points.
Be aware, this will delete your wanted breakpoints as well.
Related
Lately, VS has been getting more and more annoying about warning me about editing code while debugging. Regardless of whether it is a popup telling me that a file has been edited, purple underlining, or a warning that gets grouped with the compiler warnings and errors, I don't want it. I wish it would just let me edit, continue running the program that was built, and keep quiet about it.
Is there a way to tell it to do that?
Incidentally, I have already disabled edit and continue. See Edit and Continue: "Changes are not allowed when..."
You can apply changes to the source code in debug mode when you stop at a breakpoint.
Manual: How to: Apply Edits in Break Mode with Edit and Continue (Visual Basic)
This is a workaround but some workarounds, well, work.
Run two instances of VS on the same solution. Debug one and encounter needed edit. Ctrl+TAB to the other instance and make the edit (without saving... by the way use auto-save). Continue until you’re done, and then save the files in instance 2. After debug, the changes are available to both instances.
Rarely (at least in my experience) do you actually want edit-and-continue; usually you’re watching the code under debug and realize it is wrong and want to fix it, but also want to see some downstream effects without killing the debug session.
This gives you that with a minor inconvenient task switch.
I have a .NET Core 2.1 solution containing 2 F# projects, one class library and one executable. When I run the executable project with the command:
dotnet run --project ServerProject
it shows the Suave.IO log message immediately:
Smooth! Suave listener started in 92.632ms with binding 0.0.0.0:3000
However when I try to debug in Visual Studio (2017 or 2019 Preview) nothing appears on the dotnet.exe window at all — unless I pause debugging and continue, at which point it will carry on as usual and display the log message immediately.
I have set breakpoints to try and figure out where it gets stuck but nothing special happens there at all. My code loads some data from a CSV and it somehow gets stuck at the stage where it converts the CSV's rows into some records. All breakpoints and printf statements before this function get hit but the subsequent ones don't. And every time I pause debugging it seems to pause at a different point of this cell parsing code, so it's not even hanging in the exact same place every time.
I'm fairly new to the .NET world so I'm not even sure where to start investigating. Any help would be appreciated!
EDIT:
Adding this to say that this has been happening consistently for many months now. Any ideas would be really appreciated.
This is not a duplicate question, my question is not answered in other threads. Please read before marking duplicate.
If I mark a breakpoint int Visual Studio 2013, and I leave that in there for several sessions of coding, I find that the breakpoint is duplicated. Sometimes hundreds of times. These are duplicates because they are for the same line of code. I usually click to the left of the line numbers to create my breakpoints.
My question is how do I prevent that from happening? I know how to delete them, I'm just wondering how to prevent them, which I have not seen an answer to.
The only reason I know of (that's not a serious bug) that would cause a line breakpoint in C# to have children is if your application is creating multiple (many by the looks of it) AppDomain's. As an Application Domain is created, not only is that executable code duplicated, but all of the breakpoints in that code are as well.
So, to prevent the excessive procreation of breakpoints, either stop creating AppDomains or do not set breakpoints in code executing in multiple AppDomains. There is no setting in Visual Studio to prevent this intended behavior.
So this just started: When I'm debugging a method, VS debugger does not recognize variables or objects that have been declared within the method I am debugging. When I hover over them, it does not give any pop-up intellisense. If I add it to the watch, it says:
'FooBar' is not declared. It may be inaccessible due to its protection level.
It can be something simple, like:
Dim MyString String = "this is a test"
But after moving past that line in dubugger, it won't recognize MyString. BUT, if I then use MyString, like save it to the DB or output it to the screen, it works fine. So it's really there, but debugger is not recognizing it.
Variables and objects that are passed into the method work just fine, as expected.
The first time I saw this, I did a clean & rebuild, and that solved the problem. But a few debugs later, it started up again. A clean & rebuild did not work. So I closed VS, deleted the solutions .suo file. After starting VS back up again, debug now worked as normal, for a while.
But now it's doing it again, and nothing I try seems to get it back working again.
I spent time on Google and have found people who have asked the same question, but I've not seen any thread anywhere with a definitive answer.
Anyone ever seen this before and whooped it?
EDIT AFTER:
Pretty sure I am doing this in debug mode. But let me know if there is some other place I should be looking.
My guess is that you are debugging a 'Release' configuration. Release configurations optimize the code by, among the many other optimizations, removing code that it knows for sure is never going to be used. So, for example, Dim MyString String = "this is a test" will be optimized out of the solution if it is never used but if you add a line of code to commit it to a database it is then being used and will not be optimized out. Switch to the 'Debug' configuration to prevent these types of optimizations.
I have a really strange problem with my Visual Studio.
I usually press CTRL + S pretty often (call me paranoid, well however I got that habit some years ago now and I really don't want to get rid of it :-))
Now I had the issue that I was editing one file, changing a few dozen of strings according to a spec I had open in Word; so I switch around these two tasks pretty often, make one or two changes and then save.
The odd thing is, every once in a while, after saving, my file is suddenly in read-only-mode, so I cannot navigate through my changes (CTRL+Z/CTRL+Y) and have to reopen that file to continue to code and pray.
Indeed it feels random to me when this occurs:
sometimes I only change 1 thing and save and then it's immediately read-only,
well in other cases it will let me edit several things until it is stuck.
Someone else also experiencing this and maybe got a tip?
Maybe I hit some magic hotkey or something?
My bad, please check if your projects folder is not a synchronized one, so when you edit (change) your project, the backup tool starts to update in remote location for synchronization purposes, so locks the file.
The answer to this problem is most likely that you are currently in Debug mode - i.e. the application is being run. Click "Stop" and it'll allow you to edit the files again.
By default, you cannot edit source files while the Debugger is running.