[wasm][debugger] Properties in the watch window show "𝑓 <Property>" instead of the value of the property

[RobertBouillon]

Describe the bug

Watch window does not show the value of properties for Blazor WASM projects, requiring you instead to navigate to and expand each property to see its value.

To Reproduce

1. Create a new Blazor WASM project
2. Add a new .NET library project to the solution
3. Add the Foo class to the library with the code below
4. Add a reference to the .NET library project from the WASM project
5. Update the FetchData.razor page with the code below.
6. Add a breakpoint in the Bar property
7. Start debugging
8. Click on the "Fetch Data" link in the window
9. The program should break in the Foo class. Open the locals Window

Expected Results

this.Bar will show the value sample-data/weather.json

(Image shown is the locals window when the same value is viewed from a console project)

Actual Results

this.Bar shows 𝑓 Bar() {} and requires you to expand the property to view the value

Foo.cs

using System;

namespace BlazorBugsLib
{
  public class Foo
  {
    public string Bar => "sample-data/weather.json";
    public string Lorem { get; set; } = "Safe";
    public string Ipsum { get; set; } = "Side";
    public Something What { get; } = new Something();
  }

  public class Something
  {
    public string Name { get; set; }
    public Something() => Name = "Name of something";
    public override string ToString() => Name;
  }
}

FetchData.razor

  protected override async Task OnInitializedAsync()
  {
    forecasts = await Http.GetFromJsonAsync<WeatherForecast[]>(new BlazorBugsLib.Foo().Bar);
  }

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Describe the bug

Watch window does not show the value of properties for Blazor WASM projects, requiring you instead to navigate to and expand each property to see its value.

To Reproduce

1. Create a new Blazor WASM project
2. Add a new .NET library project to the solution
3. Add the Foo class to the library with the code below
4. Add a reference to the .NET library project from the WASM project
5. Update the FetchData.razor page with the code below.
6. Add a breakpoint in the Bar property
7. Start debugging
8. Click on the "Fetch Data" link in the window
9. The program should break in the Foo class. Open the locals Window

Expected Results

this.Bar will show the value sample-data/weather.json

(Image shown is the locals window when the same value is viewed from a console project)

Actual Results

this.Bar shows 𝑓 Bar() {} and requires you to expand the property to view the value

Foo.cs

using System;

namespace BlazorBugsLib
{
  public class Foo
  {
    public string Bar => "sample-data/weather.json";
    public string Lorem { get; set; } = "Safe";
    public string Ipsum { get; set; } = "Side";
    public Something What { get; } = new Something();
  }

  public class Something
  {
    public string Name { get; set; }
    public Something() => Name = "Name of something";
    public override string ToString() => Name;
  }
}

FetchData.razor

  protected override async Task OnInitializedAsync()
  {
    forecasts = await Http.GetFromJsonAsync<WeatherForecast[]>(new BlazorBugsLib.Foo().Bar);
  }

Author:	RobertBouillon
Assignees:	-
Labels:	arch-wasm, area-Debugger-mono, untriaged
Milestone:	-

[lewing]

I'm fairly sure this is the expected behavior, you can expand the property manually.

cc @radical

[RobertBouillon]

I'm fairly sure this is the expected behavior, you can expand the property manually.

cc @radical

Shouldn't the behavior of the watch window be the same, regardless of the runtime?

I don't see the benefit to the change in behavior for WASM/Mono - it doesn't improve debugging, and I'd argue it makes the watch window less useful.

It's been a pain point for me while debugging - when I need to inspect the value for 3 or 4 properties of an object, it's annoying to go into the watch window and expand the values each time.

[radical]

The reason for having it show up as a function that you have to expand was that property getters can have side effects, throw exceptions etc, so require an explicit action to invoke the getter. AFAIK, VS does some custom behavior by analyzing the code, @vargaz or @thaystg might know better. I wonder if the recent debugger changes would allow us to do something better, eventually.

Ipsum, Lorem are properties backed by fields, so we can directly read them, that's why they don't show up as functions.

As for the ToString() thing, I can take a look at that.

[RobertBouillon]

There is an option in Visual Studio to disable implicit function calls. I have implicit calls enabled in my options, so I would expect that to be the behavior unless I disable it.

property getters can have side effects

Accessors are expected to be free of side-effects. That's consistent with my experience - I've never had an accessor cause a side-effect.

so require an explicit action to invoke the getter

The current design language for the watch window is to provide a blue "refresh" button for values that require explicit invocation. Here is the same class in .NET Core with implicit function evaluation disabled in VS.

If this is a technical limitation of the WASM/Mono debugger, my hope is that we could keep an issue open so that it can be appropriately prioritized. If you're saying this is a design decision, I would like to politely object to the change. If function evaluation needs to be deferred, it should be consistent with how the Core/FW runtimes defer execution, which has additional functionality attached to it, such as optionally forcing execution. The current WASM implementation also prevents access to the mutator from the watch window - from an API perspective, Properties should be functionally equivalent to fields, and that's how I'd expect them to be represented in a watch window.

[danmoseley]

Accessors are expected to be free of side-effects.

I don’t have context on this issue, but accessors can have side effects that are relevant to debugging, for example populating a cache, loading a type, etc.

[lewing]

@thaystg this falls into the VS settings set. Please triage this along with the other settings and move it appropriately.