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

Question

In the project properties Build Events I use

echo %date% %time% > "$(ProjectDir)\Resources\BuildDate.txt"

To update the build date the file, "BuildDate.txt" was added in the project properties to the Resources collection as a "file". This worked in VS2017 but in VS2019 unaccountably, neither the watch nor the mouse hovering over "Properties.Resources.BuildDate.ToString()" can show the value. Not only the value, but the debugger does not even think that "Resources" exists! I misspelled some text in the image, too late to edit. Sorry. App is small and is over at github "jstateson"

]1

Answer 1

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.