ASP.NET Core 3.1 - Debug tooltip does not show value

[ghost]

Please advise if this bug belongs here. WEBTOOLS has said it is not from their systems. I am posting this here because of the following statement by @ToddGrun in an email:

I think it’s the debugger team that provides the tooltip, but the Roslyn team would know better.

---

.NET Core 3.1 version 3.1.200-preview-014977

• Create a new ASP.NET Core MVC project. Target the 3.1 (preview) sdk
• Open a view, add some valid code in a "@{ }" block
• Run the project in Debug mode and attempt to debug the value of the variables in the "@{ }" block

You will see the problem when you hover over the variable name during the debug session. Instead of showing the value of that variable at that point, it shows its declaration. For example, instead of showing the value (of an int) as 1, it would show (local variable) int i.

The debug tooltip works fine in the Controller and other classes, etc in the same project. The problem only affects the code in the view's server-side code.

Here is a screenshot: In the screenshot, one would expect to see the value of the isEditMode variable, instead of its declaration.

Also tagging folks that were part of the email thread on this: @jodavis, @jinujoseph

[tmat]

/cc @NTaylorMullen

[NTaylorMullen]

/cc @NTaylorMullen

I imagine it's an issue where the line pragmas behind the scenes map to more than what's visible and then Roslyn or the Debugger ( I don't know who owns that code ) improperly associate what the user is hovering over because of that.

[ghost]

@NTaylorMullen All the variables [isEditMode, data] visible in that screenshot are right there, and just a couple of lines above. It actually does not matter where and how the data comes from. The debugger does this for ALL variables in a View's code.

[NTaylorMullen]

@sujayvsarma how Razor works is it generates hidden documents to break the document into the various languages (you can't see those hidden documents). So there's a lot behind the scenes running and being analyzed by the debugger/Roslyn that is not directly visible to the user. Aka just because you can see the variables doesn't mean the Debugger fully understands the context. In your example all your code is being surrounded with

#line default
#line 123 C:/path/to/razor.cshtml"

// YOUR CODE

#line hidden

But you aren't able to see those pragmas because they're in our hidden document

[ghost]

You're talking about the .g.cs files in the obj\ path, aren't you?

What should I look for in those files to help find the issue you're referring to?

There are very few lines like #line [number] [path to .cshtml]" and a lot of lines that go #line default and #line hidden. And quite a lot that do #nullable disable and #nullable restore (I have nullable enabled in the .csproj).

[NTaylorMullen]

You're talking about the .g.cs files in the obj\ path, aren't you?

Kind of. The .g.cs in obj are the files that inform the debugger to jump to which file in VS. Now once in VS there's an entirely different set of logic that the debugger follows where it looks at its in-memory representation of those files (we generate different code in the editor) and attempts to map the two together to provide you a good experience.

What should I look for in those files to help find the issue you're referring to?

Honestly there's not much you can dig for in order to help; although I love the willingness to jump in 😄 . At this point the debugger team or Roslyn folks will have to debug through their VS code to figure out what's going on

[ghost]

Been too long. Closing issue.

[CyrusNajmabadi]

Reactivating. Please only close if the issue doesn't repro any more.