Suddenly when I am debugging, say I remove a break point I no longer need then hit play or restart my program, and suddenly the same break point is back.
I clear it again save, and it is back again.
In some cases I remove a break point in others I add a break point.
It seems at random it either brings back or removes the break point or moves the existing break point a line or 2 to the wrong spot.
I have tried restarting VS a few times which works at first but for only a short time.
I have never seen this before and it scares me VS could be behaving so badly.
Is there any easy solution such as clean break points (I would rather not remove all of them)?
In my experience, the behavior you describe is a sign that the .suo-file (solution-wide user options - located in the solution folder) is corrupt. To test this, you can rename or move the file to an other folder. After that, all your breakpoints and many other settings (e.g. which code-files were opened) will be gone, but the breakpoints should behave as usual again.
Edit:
If you don't want to lose your breakpoints, you can export and import them from the breakpoints-window. I think this is a new feature of VS2012 (I tried it in the Premium Edition).
An other possibility is that you are encountering a "feature" that is described here:
http://connect.microsoft.com/VisualStudio/feedback/details/391642/permanently-remove-a-breakpoint-in-visual-studio-during-debugging
Related
Recently started a new project is VS2019 and "Edit and Continue" doesn't seem to be supported. By this I mean that I've enabled the various settings for it to work based on what I've found online and it simply doesn't seem to be possible.
Is this something incredibly daft that I'm doing or not doing, or does it just not work in VS2019 and I should go back to VS2017? Thanks.
Immediately after running in debug mode, edit any line of any file to get this:
Is this something incredibly daft that I'm doing or not doing, or does
it just not work in VS2019 and I should go back to VS2017?
The premise of Enable Edit and Continue in C# is that you should set a breakpoint in that function or just in the Page_Load function. And when you do some code changes or any others,you should move the cursor to the changes, and then VS will apply these changes while debugging.
Besides, when you do these changes and click Continue, these changes will be applied in the current debug process but you can not re-execute the breakpoint at the same time.
Solution
Set a breakpoint at the beginning of the method you want to debug. And when you write some changes later, please move the cursor into the changes so that the changes will be applied.
Then you can see the successful message about this.
Note that these changes are stored in a temporary repository for debugging purposes only and are not built into the output file at the same time. They are only built into the output file when you stop and restart debugging. And this is quite different from the C++ mode.
Hope it could help you.
I am working with Visual Studio 2015.
I have a big c# class file with lot of properties and methods. I want to set breakpoints to all possible lines (set and get of properties, methods) at once. How can I do that?
You could add Debugger.Break() on the end of every single line. Therefore you could use the search and replace function of visual studio and replace \n with Debugger.Break()\n (Remember activating the regular expression option). This would cause the debugger to break at every single line, even though you won't have an indicated breakpoint.
I don't think that there's a method to add normal vs breakpoints to every single line though, due to the fact that it's quite useless, considering that you normally just step through the code with F11.
I think you are looking for this,
steps to follow:
1) Add a break point on the first line of code you want to debug.
2) Run the application.
3) When you want to run the next line of code, Select Debug | Step Into
4) Repeat step #3 for each line of the code
With vim (vsvim) you can set a breakpoint, move down a line, then repeat however many times you like, eg:
{Escape}qq:vsc Debug.ToggleBreakpoint{Enter}jq100#q
will set breakpoints on the next 100 lines
edit: here is example video, wouldnt let me embed gif https://imgur.com/SFhlEr7
Step Into(F11) or use the Debugger.Break() or add breakpoint directly would be the workarounds for you, of course, I suggest you use the Step Into(F11) which was much more convenient.
If you could use the latest VS2017 version, it has a new feature "Run to Click" which is also a better workaround for you during debugging.
Actually you don't have to debug every line code, that's also the reason I suggest you use this new feature.
Run to Click: Simply click the icon next to a line of code while debugging to run to that line. No longer set temporary breakpoints or
perform several steps to execute your code and stop on the line you
want. Now while stopped at a break state under the debugger, the Run
to Click icon subtly appears next to the line of code that your mouse
is hovered over. Move your mouse to the icon and click the button, now
your code will run and stop on that line the next time it is hit in
your code path. Turn it off from Debug> Options > Enable Run to
Click.
Reference:
https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes
Open a feature request with Microsoft https://learn.microsoft.com/en-us/visualstudio/ide/suggest-a-feature?view=vs-2022
There should be a mode that visual studio can be put in so that it automatically stops on every line of code in a particular project. This would be VERY valuable when you attach the debugger to a pre-existing process and you don't know where in the app is the current point of execution is, ie: web apps where you do not know the entry point.
I'm having a really strange problem that I just can't figure out. Things I compile in Visual Studio 2015 (C# projects in WinForms and WPF) will not launch outside of Visual Studio. This includes a project that is completely new and untouched. As in, create a new WPF Application, build in debug and release. Go to containing folders click on EXEs and...nothing.
When I run them I get 3 processes appearing in Task Manager (named the same as my application) than cannot be killed (through task manager or command prompt) and nothing else occurs. Nothing in event viewer that seems to correspond to the app. I've attached an instance of VS 2015 to the process and I get the following message: WpfApplication.exe has triggered a break point. Pressing Break takes me to a screen that tells me no debug information is available and pressing continue has no visible effects (I can occasionally see slight movement in the cpu % but not a lot else). Any attempt to stop debugging will cause visual studio to hang and when I end its process VS closes but its memory is not freed up according to Task Manager. All of these same things occur when building in VS2013 and attempting to run outside of VS. Everything runs just fine when run in debug mode inside Visual Studio but outside of it...not a chance.
I literally have no idea where to proceed from here. I can find no error messages or clues to point me in a direction to look. Is there something I'm missing/doing wrong? What steps can I take from here to find the source of the problem?
I've considered it may be something wrong with my computer but I want to explore the possibilities before I do something drastic like a clean install. If the prevailing opinion lies that way then I'll seek help elsewhere!
tl;dr: launching the exe of a compiled application results in no running application and no obvious error messages, how can I proceed from here?
I'm going to post an answer to this because I found out what was wrong but it probably isn't useful to have it hanging around so I'll just delete the question at some point soon.
The main lesson to remember is that the main purpose of anti virus software is to frustrate you as much as possible and if something weird is happening try turning it off briefly and see what happens. You'll probably find that things are now working correctly.
EDIT: I should restate this in a more serious fashion.
Anti virus can sometimes affect things in unexpected ways and turning it off temporarily can save you a lot of time. Keep it up to date too, mine was a version or so old and was not functioning correctly. I updated it and the deep scan now functions as expected rather than silently failing.
I recently posted about a bug in MonoMac in which the window would abruptly disappear after clicking on a button 20 times or so. That bug, it turned out, doesn't seem to affect Xamarin.Mac, so I switched my project to that.
But now I'm seeing virtually the same bug in a different context: after typing a few lines of text into an NSTextField, the window disappears in exactly the same manner. No error, no exception; it just vanishes. Poof, gone!
I've reproduced this in a trivial project: you can see it yourself by creating a new empty Xamarin.Mac project, adding this code in a new file, and running. Then mash the keyboard a little while. After 5 or 6 lines, the window disappears.
(Note that the app menus continue to work, writing log messages and executing my code when I select the menu commands. So it doesn't appear as though the app itself has crashed.)
Curiously, this seems to only occur when the field is inside an NSView subclass where IsFlipped has been overridden. But it doesn't matter whether IsFlipped returns true or false -- if the method is there at all, the bug occurs; if commented out, the bug does not seem to occur.
So: Has anyone else run into this sort of bug in Xamarin.Mac? Perhaps in other contexts that will give us more clues as to a root cause? Any debugging tips for a Xamarin newbie?
(I know I could work around it in some projects by avoiding IsFlipped, but I worry that it would just pop up to bite me in some other way.)
OK, it turns out that this isn't a bug in Xamarin.Mac at all, but in my code. Because I wasn't retaining a reference to the NSWindow object, it went out of scope, and as soon as the garbage collector gets around to noticing it, it's disposed and the GUI window is torn down.
All we have to do is retain a reference to the window (for example, in the AppDelegate class), and the problem goes away.
Hats off to Chris Hamons at Xamarin, who jumped right on this and quickly found the problem for me.
I might have a hard time explaining this because I am at a total loss for what is happening so I am just looking for some guidance. I might be a bit wordy because I don't know exactly what is the relevant information.
I am developing a GUI for a project that I am working on in using .Net (C#)
Part of the interface mimics, exactly, what we do in another product. For consistency reasons, my boss wants me to make it look the same way. So I got the other software and basically copied and pasted the components into my new GUI.
This required me to introduce a component library (the now defunct Graphics Server GSNet, so I can't go to them for help) so I could implement some simple graphs and temperature/pressure "widgets."
The components show up fine, and when I compile, everything seems to work fine. However, at some point during my programming it just breaks. Sometimes the tab that these components are on starts throwing exceptions when I view the designer page (A missing method exception) so it won't display. Sometimes JUST those components from the GSNet library don't show up. Sometimes, if I try to run it, I get a not-instantiated exception on one of their lines of code in the designer code file. Sometimes I can't view the designer at all.
No matter what I do I can't reverse it. Even if I undo what I just did it won't fix it. If it happens, I have to revert to a backup and start over again.
So I started to backup pretty much every step. I compile it and it works. I comment out a line of code, save it, and then uncomment that same line of code (so I am working with the same exact code) and the components all disappear. It doesn't matter what line of code I actually comment out, as long as it is in the same project that these components are being used.
I pretty much have to use the components. . . so does anyone have any suggestion or where I can look to debug this?
The only thing that comes to mind is a read-only bin directory. I've found that .NET has trouble if the interop libraries in the bin directory are read-only. Read-only interops generally prevent controls using those interops from displaying in the form designer and thus mess up compilation (if you do a full build anyway). A rebuild might let you get the app running and then fail when it reaches the part using the read-only interop.
This may or may not be your problem but it's all that comes to mind.
I know this is very late to the game, but I just ran into this same problem.
I'd pulled down one of our applications from SVN, and when I first tried to open the main form for editing, I was prompted with the custom component not being defined in the software, even though I could plainly see it as a class. I was given a choice to ignore it, which I did, and the custom control promptly disappeared from the form (still showed up in the project).
So at the suggestion of my colleague, I deleted the instance from my hard drive, and re-checked it out from SVN. Before i did anything else, I built the project for both release & debug, and that fixed the problem.
Maybe this'll help someone else who finds this SO question when they run into this.