Blazor WASM "step over" doesn't work properly for referenced assemblies

[RobertBouillon]

Describe the bug

Pressing F10 (Step Over) when debugging a WASM project doesn't always step over the current expression. This can be frustrating when debugging because the STEP OVER command acts unpredictably

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 method of the Foo class where var d is defined.
7. Start debugging
8. Click on the "Fetch Data" link in the window
9. The program should break on the breakpoint added in step 6
10. Press F10 (or otherwise select STEP OVER in VS)

Expected Results

The current executing line of code should progress to the following line with Console.WriteLine

Actual Results

The current executing line of code remains on the current line and requires a second press to continue as expected.

Notes

This only appears to affect code in referenced assemblies. If the body of Bar is copied to OnInitializedAsync, STEP OVER behaves as expected. Upon deeper investigation, it appears that the operands of && are being treated as separate lines of code when debugged from the referenced library.

Foo Class

public class Foo
{
    public void Bar()
    {
      var a = 1;
      var b = 2;
      var x = "Stew";
      var y = "00.123";
      var c = a + b == 3 || b + a == 2;
      var d = TimeSpan.TryParseExact(y, @"ss\.fff", null, out var ts) && x.Contains('S');
      Console.WriteLine(d);
    }

FetchData.razor

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

[dotnet-issue-labeler]

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.

[mkArtakMSFT]

@lewing FYI

[ghost]

Tagging subscribers to this area: @CoffeeFlux
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Describe the bug

Pressing F10 (Step Over) when debugging a WASM project doesn't always step over the current expression. This can be frustrating when debugging because the STEP OVER command acts unpredictably

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 method of the Foo class where var d is defined.
7. Start debugging
8. Click on the "Fetch Data" link in the window
9. The program should break on the breakpoint added in step 6
10. Press F10 (or otherwise select STEP OVER in VS)

Expected Results

The current executing line of code should progress to the following line with Console.WriteLine

Actual Results

The current executing line of code remains on the current line and requires a second press to continue as expected.

Notes

This only appears to affect code in referenced assemblies. If the body of Bar is copied to OnInitializedAsync, STEP OVER behaves as expected. Upon deeper investigation, it appears that the operands of && are being treated as separate lines of code when debugged from the referenced library.

Foo Class

public class Foo
{
    public void Bar()
    {
      var a = 1;
      var b = 2;
      var x = "Stew";
      var y = "00.123";
      var c = a + b == 3 || b + a == 2;
      var d = TimeSpan.TryParseExact(y, @"ss\.fff", null, out var ts) && x.Contains('S');
      Console.WriteLine(d);
    }

FetchData.razor

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

Author:	RobertBouillon
Assignees:	-
Labels:	area-VM-meta-mono, untriaged
Milestone:	-

[ghost]

Tagging subscribers to this area: @thaystg
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Describe the bug

Pressing F10 (Step Over) when debugging a WASM project doesn't always step over the current expression. This can be frustrating when debugging because the STEP OVER command acts unpredictably

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 method of the Foo class where var d is defined.
7. Start debugging
8. Click on the "Fetch Data" link in the window
9. The program should break on the breakpoint added in step 6
10. Press F10 (or otherwise select STEP OVER in VS)

Expected Results

The current executing line of code should progress to the following line with Console.WriteLine

Actual Results

The current executing line of code remains on the current line and requires a second press to continue as expected.

Notes

This only appears to affect code in referenced assemblies. If the body of Bar is copied to OnInitializedAsync, STEP OVER behaves as expected. Upon deeper investigation, it appears that the operands of && are being treated as separate lines of code when debugged from the referenced library.

Foo Class

public class Foo
{
    public void Bar()
    {
      var a = 1;
      var b = 2;
      var x = "Stew";
      var y = "00.123";
      var c = a + b == 3 || b + a == 2;
      var d = TimeSpan.TryParseExact(y, @"ss\.fff", null, out var ts) && x.Contains('S');
      Console.WriteLine(d);
    }

FetchData.razor

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

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

[CoffeeFlux]

cc: @radical @thaystg

[ghost]

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

Issue Details

---

Describe the bug

Pressing F10 (Step Over) when debugging a WASM project doesn't always step over the current expression. This can be frustrating when debugging because the STEP OVER command acts unpredictably

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 method of the Foo class where var d is defined.
7. Start debugging
8. Click on the "Fetch Data" link in the window
9. The program should break on the breakpoint added in step 6
10. Press F10 (or otherwise select STEP OVER in VS)

Expected Results

The current executing line of code should progress to the following line with Console.WriteLine

Actual Results

The current executing line of code remains on the current line and requires a second press to continue as expected.

Notes

This only appears to affect code in referenced assemblies. If the body of Bar is copied to OnInitializedAsync, STEP OVER behaves as expected. Upon deeper investigation, it appears that the operands of && are being treated as separate lines of code when debugged from the referenced library.

Foo Class

public class Foo
{
    public void Bar()
    {
      var a = 1;
      var b = 2;
      var x = "Stew";
      var y = "00.123";
      var c = a + b == 3 || b + a == 2;
      var d = TimeSpan.TryParseExact(y, @"ss\.fff", null, out var ts) && x.Contains('S');
      Console.WriteLine(d);
    }

FetchData.razor

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

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

[lewing]

closing assuming this is fixed in #55915 @thaystg please reopen if not.