Vote: To be able to debug static variables

There is an old bug that does not allow you to debug static variables in VS. Can I please ask you to vote on this issue so that it gets fixed? Link.

I just tested the steps specified in that report and I had no issue. The value of that variable was displayed when mousing over it and I was able to both get and set it in the Immediate window. I'm using VS 16.5.5.

I ran the test in VS 2013 and could hover to see the value.

I've definitely seen people have certain issues in certain software that doesn't seem to be the case for others, so that it works for us doesn't necessarily mean that you're mistaken, but it does mean that it's not the normal behaviour. There must be something specific about your installation that causes it that is not the case for us. If you haven't already, I'd suggest trying a repair first and, if that doesn't work, a complete reinstall. Not with VS but I've had both of those fix issues in other software. I can't upvote an issue that i can't reproduce and Microsoft aren't going to try to fix one that they can't reproduce, so steps that only show an issue in certain cases won't be enough.

Quote:

---

Originally Posted by jmcilhinney

I've definitely seen people have certain issues in certain software that doesn't seem to be the case for others, so that it works for us doesn't necessarily mean that you're mistaken, but it does mean that it's not the normal behaviour. There must be something specific about your installation that causes it that is not the case for us. If you haven't already, I'd suggest trying a repair first and, if that doesn't work, a complete reinstall. Not with VS but I've had both of those fix issues in other software. I can't upvote an issue that i can't reproduce and Microsoft aren't going to try to fix one that they can't reproduce, so steps that only show an issue in certain cases won't be enough.

---

I didn't dig any deeper then just scanning this link but it may be because of were the variable is defined. Mainly because it is a bit over my head :blush:

https://stackoverflow.com/questions/...-class-members

Quote:

---

Originally Posted by TysonLPrice

I didn't dig any deeper then just scanning this link but it may be because of were the variable is defined. Mainly because it is a bit over my head :blush:

https://stackoverflow.com/questions/...-class-members

---

That's for C++ so won't be relevant to VB.NET. The C++ static keyword is different to the VB Static keyword and is basically the same as the VB Shared keyword. In VB, a Static variable is basically an instance field that is only accessible in one method.

Based on the description in the link, my response was: Meh.

I've never been willing to totally rely on hovering the mouse over any variable. Sometimes I get what I expect, sometimes I don't, so I often go to Shift+F9, which wasn't mentioned. The other techniques mentioned were adding a watch variable and using the Immediate window. I never do the latter, so I have no comment on it, and as to the former, there are too many ways that the error message could be totally correct, so I can't say anything about that. Static variables would reasonably not be in scope in lots of places where you might think you could access them.

Quote:

---

Originally Posted by Shaggy Hiker

Based on the description in the link, my response was: Meh.

I've never been willing to totally rely on hovering the mouse over any variable. Sometimes I get what I expect, sometimes I don't, so I often go to Shift+F9, which wasn't mentioned. The other techniques mentioned were adding a watch variable and using the Immediate window. I never do the latter, so I have no comment on it, and as to the former, there are too many ways that the error message could be totally correct, so I can't say anything about that. Static variables would reasonably not be in scope in lots of places where you might think you could access them.

---

The report provides specific instructions to reproduce the issue though. Did you follow those instructions? The variable IS in scope where those instructions specify to check.

OK, I have installed the latest version of VS and I have tried it again. It is not working.

Code:

---

Sub Test()
    Static foo As Integer = 5

    Stop
    Console.WriteLine(foo)
End Sub

---

You can try adding foo to a Watch List, you can try Shift+F9, it won't display a value.

I tried your codes and I get both values of foo and value on VB 2010. I should try on VB2017
Attachment 177027

EDIT : tried also on VB 2017 and I get also the values for both

Not in my case:
https://snipboard.io/EVix7A.jpg

Quote:

---

Originally Posted by riov

Not in my case:

---

Then I can only conclude that there is something wrong with your installation of VS. Either it is some standard interaction between components or lack of some component that the rest of us don't have because we have installed different components or else something is corrupt on your system. If you log an issue with Microsoft and they follow your repro steps and don't see the aberrant behaviour, they won't investigate it any further. If several of us don't see the behaviour you describe then chances are that Microsoft wouldn't either. The fact that you have had to come here asking for us to upvote the issue indicates that few others have seen it either, although might be partly due to the fact that few people use Static variables. Basically, if you expect Microsoft to look more closely, you're going to have to provide steps that all of us could follow in order to reproduce the issue. I won't be upvoting an issue that I can't reproduce and neither should anyone else.

On the link I saw you are working on VS2019V16.4, did you try on an other version ?

it seems that you are not alone with that problem, maybe a question of version? link

Reproducible on VS2019 16.6.0 Preview 6 and on VS2017 15.9.23. Both clean installations, no options changed, lots of components installed (.NET desktop, ASP.NET, mobile, .NET Core, etc.).

I have tried it on VS 16.2.0 and VS 16.5.5. I have different PCs, which have different OS.

I haven't tried anything at this point, just reading the thread, but I'm wondering if targeting a Release build vs a Debug build would make any difference (can accept I may be completely off base here).

Quote:

---

Originally Posted by jmcilhinney

The report provides specific instructions to reproduce the issue though. Did you follow those instructions? The variable IS in scope where those instructions specify to check.

---

What part of "Meh" wasn't clear?

My point was that the report didn't move me enough to take the minimal action of voting on it. If the issue was something I encountered, then I would have voted for it. If the issue was something I thought sufficiently likely to encounter that I cared about it, I'd at least vote for it. As it was, it didn't move me in any way. I would expect that there are others like that, and I'd say that people should save their passion for their passions. If this matters to you, then vote for it, if it doesn't move you, there are likely things that will.

Now that I see the message, I see that fairly often on non-static variables, but only when debugging dlls, and usually only for variables not declared at the top of the method. Beyond that, the only pattern I've ever been able to put to it is that the issue will only occur when it is the most aggravating. That's only semi-facetious, as the issue isn't random, but it appears to be totally unrelated to this issue.

Quote:

---

Originally Posted by peterst

Reproducible on VS2019 16.6.0 Preview 6 and on VS2017 15.9.23. Both clean installations, no options changed, lots of components installed (.NET desktop, ASP.NET, mobile, .NET Core, etc.).

---

The test I have done on VS 2017 was on version 15.9.22.

Quote:

---

Originally Posted by Delaney

The test I have done on VS 2017 was on version 15.9.22.

---

If you have changed some settings it could work different. I've checked on unattended setup used for compiling only. It is also reproducible on my dev machines, but since I was not sure what options are changed since the initial setup, I decided to use clean install.

Mystery solved :D

- Console project: foo not accessible due to protection level
- Windows forms project: static foo accessible and everything works fine (watch, hovering)

Quote:

---

Originally Posted by peterst

Mystery solved :D

---

At least in one of my PCs that is really the case. I will check my other setups a little bit later. However, issue still remains for console apps.

Quote:

---

Originally Posted by peterst

Mystery solved :D

- Console project: foo not accessible due to protection level
- Windows forms project: static foo accessible and everything works fine (watch, hovering)

---

I just did a little testing and it doesn't appear to be the type of project that matters but, rather, whether the code is in a class or a module. I just tried this in a Console Application project:

vb.net Code:

Module Module1
 
    Sub Main()
        Dim s = GetValue()
    End Sub
 
    Public Function GetValue() As System.String
        Static value As System.String
        value = "Lalala"
        Return value
    End Function
 
End Module

and I did see the undesirable behaviour. I then tried this:

vb.net Code:

Public Class Class1
 
    Public Function GetValue() As System.String
        Static value As System.String
        value = "Lalala"
        Return value
    End Function
 
End Class

vb.net Code:

Module Module1
 
    Sub Main()
        Dim c As New Class1
        Dim s = c.GetValue()
    End Sub
 
End Module

and it worked as it should have. It seems that the issue is a Static local variable in a module. I'm guessing that it has something to do with the fact that, behind the scenes, a Static variable is actually a member variable that is hidden by the IDE outside of the specific method it's declared in and member variables in a module are effectively Shared fields in a class. The IDE may be looking specifically for an instance field implementing the Static variable and fails to find one. That seems like information that Microsoft could definitely work with. That said, the automated reply in that issue thread mentions prioritising issues that affect a lot of people so they may still consider Static variables in a module to be used so little as to not warrant attention. At least you can try though.

jmcilhinney, you are right - it is about internal representation of modules, classes and all those little things that IDE hides for VB.NET developers. ILSpy tool reveals the code behind for people who are interested to know what happens.

For me, after seeing the generated code behind, I will avoid using them (as I never used before). It is dangerous on highly concurrent multithreaded code and will make finding bugs a nightmare.

Also C# doesn't support them and we are keeping our code base easy convertible from VB.NET to C#.

Answer on StackOverflow about similar topic has following quote:

Quote:

---

There are two reasons C# doesn't have this feature.

First, it is possible to get nearly the same effect by having a class-level static, and adding method statics would require increased complexity.

Second, method level statics are somewhat notorious for causing problems when code is called repeatedly or from multiple threads, and since the definitions are in the methods, it's harder to find the definitions.

[Author: Eric Gunnerson]

---

The quoted text is from Eric Gunnerson: Program Manager of Visual C# .NET :)

Quote:

---

Originally Posted by peterst

Also C# doesn't support them and we are keeping our code base easy convertible from VB.NET to C#.

---

Given that Static local variables is a VB-specific feature, you'd certainly never encounter this specific issue in that case either.