debugging in blazor .razor files hovering variable after dot (.) won't show popup with value

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

[severity:It's more difficult to complete my work] when debugging in a .razor file (Blazor) hovering a variable property like this: Model.Prop1 if you hover "Model" the value will show in a popup but if you hover "Prop1" nothing will happen

---

Original Comments

Feedback Bot on 09/02/2022, 04:44 PM:

(private comment, text removed)

Wenwen Fan [MSFT] on 18/02/2022, 07:53 PM:

(private comment, text removed)

Valentin Plamadeala on 18/02/2022, 08:16 PM:

(private comment, text removed)

Wenwen Fan [MSFT] on 03/08/2022, 07:49 PM:

(private comment, text removed)

---

Original Solutions

(no solutions)

[ryanbrandenburg]

We'll need a reaction from the platform in order to make this work with LSP.

[chrdlx]

Please fix this one! It's very common in a debug session to try to see values of inner objects, not just the top most... I needed to enable "Use legacy Razor editor for ASP.NET Core" in Visual Studio so I could have a proper debug session.

[REDECODE]

It's not blocking but really annoying.. expecially when, otherwise, I need to inspect the top most object and it has a lot of property and the one that I need to inspect is not one of the first (e.g .Text, .Parent, etc. ).

[maryamariyan]

Steps to Debug/Reproduce:

• Follow instructions on dotnet/razor docs for build and set and run Microsoft.VisualStudio.RazorExtensions as startup project.
• Once the Visual Studio instance pops up, then open or create a BlazorServer app from the menu.
• Run the BlazorServer app
• Set a breakpoint over a C# model which you're interested in hovering over itself and its properties within a razor file during debug mode (e.g. FetchData.razor#L25 a breakpoint over line 25 so that would help inspect values of forecast and forecast.TemperatureC upon hover)

Expected Behavior

• Expected hovering over forecast or forecast.TemperatureC to show its runtime value upon stopping at the breakpoint

Actual Behaviour

• forecast value gets printed on datatip upon hover but nothing shows up for forecast.TemperatureC

First observation

• If we were to hover over forecast.TemperatureC in a cs file rather than a razor file, even in the same solution, then the datatip value gets populated properly. So the bug has to do with how we treat this item within a razor file.

Steps to debug solution in managed/native mode:

• Open dotnet/razor solution and Microsoft.VisualStudio.RazorExtensions as startup project.
• Navigate to menu: Debug > Start without debugging
• Then navigate to: Debug > Attach to process, then select: Attach to:, and select these code types: Managed (.NET 4x) and Native, then out of the available processes select devenv.exe and hit the Attach button.
• Then load the same Blazor Server solution, run it, set a breakpoint at the same razor file, load the page and do the same inspections.
• Unselect "Enable Just My Code" and try to get the external symbols loaded, decompile could work as well.

Observation after also inspecting native dependencies:

• The native code seems to be receiving the expression TemperatureC when hover happens in razor file, as opposed to expression forecast.TemperatureC being received when being hovered over in a C# file.

Expected fix

We'll need to go over the portion of code responsible for creating these expressions in the razor files and make sure the properties are being setup properly.

[maryamariyan]

Overview of investigations

The CS code flow for data tip hover

Hovering over the model.Property in a .cs file properly shows the data tip (compared to the bug reported here happing in a .razor file). The CS logic lands under AbstractVsTextViewFilter.cs#L123-L131 in roslyn. The CS file usecase works well because roslyn has complete knowledge about the syntax tree and has access to the CS text buffer.

Given the hover location indices on the file, the roslyn logic properly transforms input span from VS data model into a Microsoft.CodeAnalysis data model TextSpan, calling into ILanguageDebugInfoService.GetDataTipInfoAsync to get the right range of text span for the property in the CS file, before transforming it back to the VS data model and span.

The razor code flow for data tip hover

RazorLSPTextViewConnectionListener.cs#L344-L345 gets triggered when a model.Property gets hovered over in a razor file.

It's possible to use the ExternalAccessor layer in dotnet/roslyn to indirectly expose ILanguageDebugInfoService.GetDataTipInfoAsync API onto the razor side using commit https://github.com/dotnet/roslyn/commit/caf4c2745d35113322ae37dae6eccd6292b0700ba with the doc directions in https://github.com/dotnet/razor/blob/main/docs/contributing/Roslyn-Debugging.md.

Existing challenge

The core problem we face when trying to use this logic is that the API expects CS text buffer and text documents but on the razor side we only have access to the razor text document and that doesn't translate well. (Commit https://github.com/dotnet/razor/commit/ab2452d7a85358ce8454f88e8d75d29a433513cd illustrates how to use the roslyn logic but proves incomplete because it is missing a proper CS text document provided as input)

Next step to try out is to add a layering change between Microsoft.VisualStudio.LanguageServices.Razor which holds and the razor data tip logic and server/client projects (Microsoft.VisualStudio.LanguageServerClient.Razor and Microsoft.AspNetCore.Razor.LanguageServer) which can be used to make an LSP call to roslyn to get text document information, similar to how proximity logic works. The remaining challenge would be to also think if it is enough to get to a TextDocument using the LSP call or could we use an SyntaxTree instead.

[bairog]

Are there any updates on this issue? The fix just gets delayed. Currently it is planned in version 17.9 (which will most likely be the last or penultimate minor version of the IDE). The bug has existed since reelase and makes debugging much more difficult - please fix it finally. The same functionality worked without problems in VS2019 since release.