Blazor WASM doesn't correctly step through code when debugging

[RobertBouillon]

Describe the bug

Stepping through code acts unpredictably, sometimes skipping over expressions that should be hit.

Workaround

You can guarantee that code will stop on a given line by adding a breakpoint. Because STEP OVER acts so unpredictably, adding a breakpoint is really the only way you can guarantee that your code is going to stop on a given line.

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 on the line with ret = 0
7. Start debugging
8. Click on the "Fetch Data" link in the window
9. The program should break in the Foo class.
10. Press F10 (or invoke the STEP OVER VS debug command)

Expected Results

The currently executing line will progress will progress to the line with return ret;

Actual Results

The debugger steps out of the function

Foo.cs

using System;
using System.Linq;
using System.Collections.Generic;

namespace BlazorBugsLib
{
  public class Foo
  {
    public string Lorem { get; set; } = "Safe";
    public int Bar()
    {
      int ret;
      if (Lorem.StartsWith('S'))
        ret = 0;
      else
        ret = 1;

      return ret;
    }
  }
}

FetchData.razor

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

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

Issue Details

---

Describe the bug

Stepping through code acts unpredictably, sometimes skipping over expressions that should be hit.

Workaround

You can guarantee that code will stop on a given line by adding a breakpoint. Because STEP OVER acts so unpredictably, adding a breakpoint is really the only way you can guarantee that your code is going to stop on a given line.

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 on the line with ret = 0
7. Start debugging
8. Click on the "Fetch Data" link in the window
9. The program should break in the Foo class.
10. Press F10 (or invoke the STEP OVER VS debug command)

Expected Results

The currently executing line will progress will progress to the line with return ret;

Actual Results

The debugger steps out of the function

Foo.cs

using System;
using System.Linq;
using System.Collections.Generic;

namespace BlazorBugsLib
{
  public class Foo
  {
    public string Lorem { get; set; } = "Safe";
    public int Bar()
    {
      int ret;
      if (Lorem.StartsWith('S'))
        ret = 0;
      else
        ret = 1;

      return ret;
    }
  }
}

FetchData.razor

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

Author:	RobertBouillon
Assignees:	-
Labels:	area-Diagnostics-coreclr, untriaged
Milestone:	-

[mkArtakMSFT]

Thanks for detailed issue report, @RobertBouillon.
@lewing FYI

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

Issue Details

---

Describe the bug

Stepping through code acts unpredictably, sometimes skipping over expressions that should be hit.

Workaround

You can guarantee that code will stop on a given line by adding a breakpoint. Because STEP OVER acts so unpredictably, adding a breakpoint is really the only way you can guarantee that your code is going to stop on a given line.

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 on the line with ret = 0
7. Start debugging
8. Click on the "Fetch Data" link in the window
9. The program should break in the Foo class.
10. Press F10 (or invoke the STEP OVER VS debug command)

Expected Results

The currently executing line will progress will progress to the line with return ret;

Actual Results

The debugger steps out of the function

Foo.cs

using System;
using System.Linq;
using System.Collections.Generic;

namespace BlazorBugsLib
{
  public class Foo
  {
    public string Lorem { get; set; } = "Safe";
    public int Bar()
    {
      int ret;
      if (Lorem.StartsWith('S'))
        ret = 0;
      else
        ret = 1;

      return ret;
    }
  }
}

FetchData.razor

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

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

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

Issue Details

---

Describe the bug

Stepping through code acts unpredictably, sometimes skipping over expressions that should be hit.

Workaround

You can guarantee that code will stop on a given line by adding a breakpoint. Because STEP OVER acts so unpredictably, adding a breakpoint is really the only way you can guarantee that your code is going to stop on a given line.

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 on the line with ret = 0
7. Start debugging
8. Click on the "Fetch Data" link in the window
9. The program should break in the Foo class.
10. Press F10 (or invoke the STEP OVER VS debug command)

Expected Results

The currently executing line will progress will progress to the line with return ret;

Actual Results

The debugger steps out of the function

Foo.cs

using System;
using System.Linq;
using System.Collections.Generic;

namespace BlazorBugsLib
{
  public class Foo
  {
    public string Lorem { get; set; } = "Safe";
    public int Bar()
    {
      int ret;
      if (Lorem.StartsWith('S'))
        ret = 0;
      else
        ret = 1;

      return ret;
    }
  }
}

FetchData.razor

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

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

[lewing]

cc @radical

[lewing]

@thaystg is this fixed now?