Develop Reference

How do I highlight class Variables in Sub-Class within Visual Studio Editor

I don't post very often and I have tried to do my research but simply cannot find if my wish is possible using the Visual Studio 2017 Community Editor. I an entry level just-for-fun programmer of C# and am now learning about sub-classes. Here is my wish (and question):
I have developed a class in a separate file (class Parent). It is a very simple class with some public variables. Now in a separate file I have another sub-class Child based of Parent (class Child:Parent). Within the class Child, I use the variables of Parent which are available to me in Child. Everything fine and the compiler doesn't flag my code for errors. So, good or bad, right or wrong, I'm getting the hang of classes and sub-classes.
My wish for the Visual Studio editor is when I look at some variables in my Child class, I find myself wondering, where did those variables come from? Where were they defined? Then I have my ah-a moment and remember they are coming from the Parent class. If I "peek definition' the code, everything is revealed to me very nicely.
But my question to you is can Visual Studio editor somehow colorize these variables that are used in the sub-class but defined in parent class? Especially when the Parent class for me is in another file which is not currently opened?
Just a wish...otherwise what I have is fine but it would be nice when looking at my code after a long time to just see these variables originating from a parent class in another color perhaps.
I did try to go through the Font-Color settings but honestly was overwhelmed and couldn't find a direct hit there.
Any help or comments on this very low priority question would be welcome.
Thank you.

I don't think there is such a feature in VS, you don't need it anyway. According to Crowcoder in the comments, this can be done by writing a Roslyn Analyzer, but I don't think you should do this just because you want to know where are the variables declared. Trust me, you don't need it.
The truth is, in most cases you are not the one who should worry about where exactly a variable is declared when you are reading code. That's the job of the compiler.
If your variables and classes are well-named, you will be able to understand immediately, without thinking about "Wait where does this come from?". For example:
class Slime: Monster {
public Slime() {
Health = 10;
}
}
Given that this code compiles successfully, do you need to worry about where Health is defined? No! It's a slime! Obviously it's gonna have a Health. Do you need to check out the definition to see what it is used for? No! From the name, we can clearly see that it represents how much health is left for the slime.
Basically, what I mean is that if you can write code with well named variables, you will be able to figure out what each variable does without looking at the definition.

Just hovering the mouse over a member variable tells you where it is declared, e.g. if in a sublcass of X and hovering over 'foo' which is an integer declared in X, it will show you int X.foo. It's not exactly what you ask, which as others commented is not easy to get, but it's by far the easiest way and doesn't require Peek Definition.

Can VS Debugger break on change of an Object ID? Similar to C++ [duplicate]

How can I track a variable's values as they change, at runtime, in C#? I'm interested in the same functionality that the debugger provides when I'm tracing a variable through execution steps, only that I need to call upon it from my code. Some sort of key-value observing, but for all kinds of variables(local, class, static, etc), not only properties. So, basically, receive a notification when a variable's value changes.

You are working from the assumption that the debugger can track variable changes. It can't.
It is possible with unmanaged code, the processor has dedicated debug registers that allow setting data breakpoints. Up to three are provided. It generates a hardware interrupt when it sees a particular memory location getting written. This otherwise very useful feature isn't available in managed code however. The garbage collector is completely incompatible with it, it moves objects around, giving them another address.
The managed debugger does support a "when hit" condition on a breakpoint, allowing you to dump info to the output window. That however requires a breakpoint, it cannot be triggered by a change in variable value. It also really slows down code execution since the debugger actually enters a break state before executing the condition.
The obvious place to put such a breakpoint is in a property setter. Which is what you'll need to implement this feature in code. You can do anything you want in that setter, using the Trace class for example.

To add to what Marc said, if you want to do this for lots of properties and methods you might want to check out aspect oriented programming techniques, and libraries such as PostSharp.
http://www.sharpcrafters.com/postsharp

The managed debugger uses the ICorDebug COM API for pretty much everything. The part that you're interested is ICorDebugValue and its descendants. Note that a LOT of the debugging API requires that the process be not running (ie, have encountered a breakpoint) in order for the various inspections to happen. A high level overview of ICorDebug is here. The documentation on it is kinda sparse, but some Googling may help. Good luck.

The only sensible way you could do that without the debugger would be: don't use a variable, but use a property, and (perhaps conditionally) add trace to the setter:
private int myValue;
public int MyValue {
get {return myValue;}
set {
SomeTraceMethod(myValue, value, ...);
myValue = value;
}
}
Obviously this cannot then be used for arbitrary fields/variables.

As others mentioned a mechanism like that makes only sense when using properties. In .NET you can then make use of the INotifyPropertyChanged interface.
For a sample how to implement it see
How to: Implement the INotifyPropertyChanged Interface
The referenced article talks explicitly about Windows Forms, but you are not bound to that (the interface is actually declared in the System.ComponentModel namespace in System.dll). In fact, this interface is widely used for data binding scenarios, e.g. in WPF.

Track an instance in C#? [duplicate]

This question already has answers here:
When debugging, is there a way to tell if an object is a different instance?
(3 answers)
Closed 7 years ago.
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.

There's nothing that I'm aware of out of the box, but VS does support conditional breakpoints. One option would be to:
Place breakpoints on all of the methods on your class that you're interested in
Debug your code through until the first of these is hit
Find the HashCode of the instance
Make all of the breakpoints coditional on GetHashCode() == the hash code you previously retrieved
Let the application run on until the breakpoint is hit again
Look in the Call Stack window to see which line of code is calling your method
A little clunky, but will work...

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.

Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible

Here is the error
Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible, possibly because the code is optimized.
I am writing a simple console app and the first line of code is this:
List<MyObjectModel> list = MyObjectModel.GetNonCompletedReturns();
and the code for the function is:
public static List<MyObjectModel> GetNonCompletedReturns()
{
MyObject service = new MyObject();
List<MyObject> entities =
(from recs in service.Retrieve() where select recs).ToList();
List<MyObjectModel> models = new List<MyObjectModel>();
foreach (MyObject entity in entities)
{
models.Add(BindModel(entity));
}
return models;
}
and if I try to step through the code, as soon as I get back to the main of my app and hover over the list, I get the error message that I showed.
Can anyone help?

If your project is compiled in release (with optimizations turned on), you may see this. Have you tried the DEBUG configuration?

This error fires only when you are trying to use Watch dialog during debug.
Try to use some other technique to output the variables, like Debug.WriteLine, Console.WriteLine and so on.

None of the answers solved my problem so I'm posting the solution that helped me.
"If there is to much data in the parameters then this error can occure,
a simple solution is to make an object, not a struct because that's a dataobject.
Put this object in your parameters instead of all the different variables,
normally the problem will no longer take place."

Here's a little trick just in case you want to examine some objects and you are not able to change the parameters:
I've created a call to a new temporary function, inside the function from where I was unable to watch my object. Then, inside that new function I was able to watch my object. After the job is done, just delete the function.

While it's true that the "Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible, possibly because the code is optimized" error appears when in release mode, most developers just ensure that their projects are configured to compile as a debug build. BUT to be sure that you have no release-DLL issues, you also must check the references to DLLs that are in your solution and make sure that you don't have a reference to a release-build DLL. If you find that this is the case, delete the DLL reference and then add a project reference rather than a DLL reference. The project reference will ensure that your solution references debug or release versions of the DLL as specified in your build configuration.
Note that the above advice applies, of course, to only those DLLs to which you have source code and which are built from a project in your solution.

I got this too, when I hit a NullReferenceException from a 3rd party control.
In this one case, I found that if I set a breakpoint before I hit the exception, I could then single step through the rest of the code without seeing the problem.
No idea why, but this worked for me - in this case at least.

For what it's worth, this error can also be caused by an infinite loop in a property getter (simplified version below). When the debugger attempts to evaluate the property (e.g. in the watch window) the UI will hang for a few seconds and the "Cannot evaluate expression..." error will appear for many of the other properties in the same class.
public int MyProperty
{
get
{
while (true) { }
return 0;
}
}

First make sure that you're running your code in DEBUG mode and with code optimization turned off. you can turn that off from the properties of your project.
If you made all of the above and the problem persists, then it's probably a problem with the stack having Debug.Break() on top of it. The solution for this is very easy, just press F10 to move to the next line and you should be able to evaluate the expression.
You can check this SO question for more information about this issue.

I was experiencing the same error message in the Visual Studio debugger when evaluating a linq expression.
Disabling the VS debugger config setting 'Enable Just My Code' resolved the issue for me:
To enable or disable Just My Code, choose the Tools > Options menu in
Visual Studio. In the Debugging > General node, choose or clear Enable
Just My Code.
https://learn.microsoft.com/en-us/visualstudio/debugger/just-my-code

I was having same issue in Visual Studio 2017. Going to Debug> Options> Debugging> General and checking "Suppress JIT optimization on module load(Managed only)" fixed my issue

Breakpoint that breaks when data changes in a managed language

I have a class with a list property that seems to lose an element under certain circumstances. I cannot find out when this happens.
So what I'd like to do is set up a Visual Studio breakpoint that will pause the program the moment this value changes. A conditional breakpoint would not work in this scenario, since I have no idea what is removing this breakpoint.
To put it another way, I want my program to stop the moment myList.Count evaluates to a new number.
Any ideas on how to do this?

This is not possible in C# or any of the other .NET languages due to CLR limitations. The Visual Studio native code debugger supports data breakpoints (link) for C++ code which do exactly this but this is not supported for managed code. You could try to break on or intercept Add and Remove method calls on the collection as suggested in the other answer to this question.

What about swapping out List<T> for ObservableCollection<T> and listen for the CollectionChanged event? It implements the IList<T> interface so there should be enough overlap in available methods to result in syntax and semantic compatibility.

This is now possible in Visual Studio 2019.
See release notes here: https://learn.microsoft.com/en-us/visualstudio/releases/2019/release-notes
This article goes into some detail using Preview 2.
https://devblogs.microsoft.com/visualstudio/break-when-value-changes-data-breakpoints-for-net-core-in-visual-studio-2019/
Note that this is for .NET Core only and not the soon-to-be-legacy full fledged Windows only .NET framework.

I'm assuming Visual Studio is IDE.
Set a breakpoint, right click it, select condition, type myList.Count, and choose Has Changed.

Subclass List<t> with your own class, then override Count (or Add/Remove) and add a breakpoint in the method you create.
EDIT: As mentioned in comments, this would require a great deal of effort since the Add and Remove methods aren't virtual; a complete rewrite of the methods would be needed.
Also, subclassing Collection<t> would apparently be a better solution (though I can't discern a reason why since Add/Remove aren't virtual members for Collection<t> either; comments?).

You can set data breakpoints in visual studio but this is going to be difficult to do for managed code, as the garbage collector may move the object around. That said, you may still be able to pull it off. You will have to enable native debugging for your process. Load SOS in the immediate window and use !DumpObject to find the address of the backing store for the Count property. Using this address, create a new data breakpoint with this address and then continue and trigger the issue.

Find all usages for this particular property and add breakpoint to all lines that removes elements from this list.
Or you may create your own IList implementation and set breakpoint to Remove method (you can't subclass List without changing all you clients, because List::Remove isn't virtual).

This is maybe more of a question than an answer, but you can step into Framework code when debugging, provided you set up your Visual studio that way. It could be that you can then put the breakpoint into the actual List implementation.

this may sound too out of the way or complex but can you use timer/background thread to keep testing the count value and do a Debugger.Break() whenever it finds the value different from its previous instance.