Thank you for using Visual Studio and for your commitment to improving it. We are currently evaluating whether we will be able to address this suggestion in a future release. Thanks for capturing the pain points you feel when stepping through multithreaded applications while debugging. We will be providing an update soon.
Additionally, I wanted to clarify that the debugger will only ever complete a step on the thread from which the step was originated. So if you hit a breakpoint, disable it, and then begin stepping you should not stop on a different thread. If you have other breakpoints in your application and another thread hits one, then you will be debugging in the mixed thread state as described in this item.
Program Manager, Visual Studio
I too agree that the proposed functionality is absolutely critical to debugging multi-threaded code. Have you ever tried to debug multi-threaded code and watch the instruction pointer stay on the same line (which causes one to think, gee - did I press the F10 key hard enough?), jump forwards, as well as jump backwards every time the step key is pressed? This is all due to multiple threads running thru the code. The debugger needs to provide a little bit of extra functionality that allows developers to control how multiple threads are run to make debugging the code easier, and without having to freeze each and every thread and then unfreeze those same threads later on - which can be quite time consuming.
This is what I would suggest:
Provide a default multiple-threaded debug mode that single steps thru the code without switching to a different thread. That makes the code easier to debug by single-stepping through the code. As others have pointed out, that is how IBM and others do it. There are two sub-modes of this mode. The first sub-mode, the default, stops all other threads from executing through the code, which in effect forces the code to be single-threaded at that point. It should do this by freezing the other threads. The developer would have the option of unfreezing specific threads later on if he should want to debug 2 or more threads running thru the code. The 2nd sub-mode allows other threads to run through the code, but only threads from the thread of interest are allowed to hit breakpoints.
The non-default multiple-thread debug mode allows multiple threads to run through the code, as is the case now. Both the mode and sub-mode should be able to be changed via a context menu or some hot-key combination at any time while debugging.
I scoured the docs to see how this could be done - it can't be done currently. So, I was about to make the same suggestion here. This is important because the Equals and GetHashCode methods allows objects to be matched that may not be bit for bit equal. In my case, there are other fields in the dictionary key that I need to retrieve which are not used in the Equals method - but can't since there is no way to do it other than perhaps iterating through the entire container which would be expensive.
This suggestion applies to any container that uses keys. This includes, Dictionary, SortedDictionary, ConcurrentDictionary, and HashSet. There may be others as well.
It would also be nice if a method could be provided that would return the index of a key inside the container. There is a method called ElementAt that can be used to access an element in a container, but there is no corresponding method that provides the position of a key within a container.
One last small suggestion is to provide a constructor to HashSet that takes a capacity like other containers - for example Dictionary.
Hi Supporters of Data Breakpoints for C#!
I am currently looking into this suggestion to investigate what the possibilities for this could be. Please take this short survey (https://www.research.net/r/DataBreakpoints1) to help me know more specifically how C# Data Breakpoints will help you in your development process.
Looking forward to hearing from you,
I can't tell you how much this is needed. Visual Studio 6 used to have this capability. I managed to solve a very difficult bug by setting a breakpoint when the value of a certain variable changed back in 2001 or so. But, it would only work on a memory address. When .NET came out in the early 2000s or so, I was very disappointed that VS no longer supported this feature. Someone from MS said that it could not be easily done because of the way memory is managed and the fact that the GC can move memory around. Well, why can't a pointer (excuse me - reference) be used to point to the area in memory where the memory manager or garbage collector is keeping track of things and then offset it from there? In fact, why not add some code and a method or two to the garbage collector / memory manager to have it automatically notify the subscriber when memory is moved so that a pointer can be used?
If I remember correctly, the dialog box for setting a breakpoint on a variable supported breaking when the value had changed or when it matched a certain value. In addition, it would be nice if it could break when the value is greater than or less than a certain value. If you really want to offer something unique, then how about providing a way for a user-written method to be called for handling more complex checks. How often should the variable check be done? Make that a user-defined option, where values could be set to after every low-level instruction, after every method call has returned, after every high-level language instruction (default), and after every high-level language method call has completed.