4

Is there a way to track a single instace in C#/.NET in Visual Studio while debugging? I find it would be really useful sometimes.

Another way to look at it would be breakpoints on instances rather than code. Therefore, every time my instance is accessed and/or modified the execution stops and I am presented with the line of code which accesses/modifies my instance.

In C++ the equivalence would be monitoring the piece of memory where the instance is located, or simply a pointer to the instance. This approach doesn't work with managed code as the objects in .NET are moved around, therefore I need an equivalence for pointers in C++.

I am aware of WeakReferences in C# but I am not sure if they are of any use while debugging?

Edit1: This question is different from "When debugging, is there a way to tell if an object is a different instance? " as I am not interested in comparing two references, but I want to access a single object.

Огњен Шобајић
  • 1,414
  • 15
  • 31

2 Answers2

1

There's nothing that I'm aware of out of the box, but VS does support conditional breakpoints. One option would be to:

  1. Place breakpoints on all of the methods on your class that you're interested in
  2. Debug your code through until the first of these is hit
  3. Find the HashCode of the instance
  4. Make all of the breakpoints coditional on GetHashCode() == the hash code you previously retrieved
  5. Let the application run on until the breakpoint is hit again
  6. Look in the Call Stack window to see which line of code is calling your method

A little clunky, but will work...

Rich O'Kelly
  • 41,274
  • 9
  • 83
  • 114
0

Add a watch, like this: https://msdn.microsoft.com/en-us/library/0taedcee.aspx

TLDNR: highlight the variable or expression you want to watch, then right-click and choose "Add to Watch" from the context menu. The variable will then be in the "Watch" window for you to observe.

As you step through your code, the expression should turn red when the value changes.

Colin
  • 4,025
  • 21
  • 40
  • This doesn't quite work. If there is a variable with the same name, that variable will be shown. Furthermore, if my variable is out of context, the watch doesn't show anything. Therefore, the watch window is scope specific. – Огњен Шобајић Aug 03 '15 at 18:17
  • Correct, you just need to formulate the watch expression according to where you want to watch the instance. Inside the class, it may be "MyProperty", but outside, it's simply "instance.MyProperty". Your question was "Is there a way to track a single instace in C#/.NET in Visual Studio while debugging?" and that really is the simplest way of doing it. Granted if you're passing the instance around it means more watch expressions to account for the new name, but the approach is well-suited for most debugging situations. – Colin Aug 03 '15 at 19:20
  • What if the "instance" is not currently available from the scope I am debugging from? I just want a global way to access the same object whatever my callstak currently might look like. Again, in C++ I can just keep an address, i.e. pointer, and I can always look up the object, but in C# pointers are useless outside the unsafe scope. – Огњен Шобајић Aug 10 '15 at 23:43
  • If there's anything to debug with an instance, you're going to have a reference somewhere on the call stack where you can "Watch" it. Otherwise, if there are no references, it's just going to get garbage collected so, as you've noticed, watching a pointer is not a very useful feature for a .NET debugger. It probably seems different/weird right now, but I bet you'll learn to like it once you've gotten used to it. :-D – Colin Aug 10 '15 at 23:58
  • No. It doesn't have to be on the call stack. Let's say it's alive, i.e. there is a reference to my object, but it's not accessible from the current call stack. – Огњен Шобајић Aug 20 '15 at 21:40
  • Typically, if it's not on the call stack, chances are there *isn't a reference* to it, which means that it will be garbage collected and "watching" the variable will be moot. There are exceptions to that rule (e.g. when multi-threading), but it's hard to envision a use case where you'd need to watch a variable that has nothing to do with the currently running code. Out of curiosity, what scenario did you run into where a watch wouldn't be sufficient? – Colin Aug 21 '15 at 16:01
  • 1
    Multi-threading is one of them, understanding a new code-base with a huge call-stack is another one. I just think it would be useful. – Огњен Шобајић Sep 04 '15 at 21:14