VS2019 debugger unable to watch a resource but the local variable obtains the value with no problem

Old question but I just encountered this and have a workaround. In my case, I have a vb.net Windows Forms app (yes I know...) and I have the form class declared ".... Class frmX / Inherits System.Windows.Forms.Form / etc. etc."

Now inside this class (class methods code) the form instance is referred to by the same name: frmX. Example:

Class frmX
    Inherits System.Windows.Form.Form
    Sub Foo()
		' I set a breakpoint on following line :
        frmX.textBox1.Text = "The width is about to change!"
		frmX.textBox1.Width = 100
etc.

Now if I stop on the last code-line and QuickWatch on it, no form of expression like e.g "frmX.textBox1.Width" works -- I get the same error as OP ( "instance required").

QuickWatch clearly thinks 'frmX' is the class name (which it IS, but it is ALSO a variable that points to an INSTANCE of that class which is what the compiler understands and is what I want QuickWatch to understand also, but alas it does not).

MY SOLUTION is to fully qualify the "frmX" instance in my expression. Instead of entering into the QuickWatch expression box

frmX.textBox1.Width ...I must enter instead... My.Forms.frmX.textBox1.Width

and then it works fine. I am forcing QW to interpret "frmX" in the proper context. Hope this helps.

Definitely an interesting problem. It actually happens in VS 2022 as well. I believe it is being caused by the debugger getting confused by the identifiers involved. My first thought was your class name. The class name matches the namespace name which is a validation of CA1724 because it can result in cases where the namespace and type cannot be distinguished without additional context making it harder to work with. While allowed in C# (because it is a little loose on the rules) it is never recommended. But changing the name of the type to something else doesn't resolve it.

My next thought was the partially qualified name. Properties is a namespace whereas Resources is the type. So Properties.Resources is the partial type name. The compiler isn't going to find the Properties type in the current namespace so it has to then look for a namespace off of your root namespace, which it will find. While it shouldn't, this could cause the debugger an issue. In fact if I add an explicit using for your Properties namespace and remove it from the typename then the debugger starts working again.

   using BoincLogAnalyzer.Properties;  
     
   string strSet = Resources.BuildDate.ToString();  

But that isn't generally how we do resources so that would be an odd thing to change. Furthermore Settings has the same problem. PropertyStore isn't even a part of the type implementation so this looks like an internal debugger lookup error. Doing a simple console app with a resource doesn't indicate an issue so it is something to do with this particular project. My recommendation is that you submit a bug report to MS and include a copy of your current project so they can look at it.

As an aside I notice all this is to support build dates. This information is actually already burned into your binary so if you want to save a little effort you can get it from the executable directly. Some sample code is provided here. This is how we used to do it when we cared about build dates (now we just use versioning). But note that deterministic build is turned on now so you need to disable that if you want to force the compiler to regenerate the metadata as discussed here.