Step-into not working properly for a method with a constructor as parameter.

[taori]

How to reproduce:

• create a new wpf application

• add nuget reference
  <package id="Amusoft.UI.WPF" version="0.2.5-alpha00112" targetFramework="net461" />

• inject codebehind code:

private void ButtonBase_OnClick(object sender, RoutedEventArgs e)
{

      //var manager = NotificationHostManager.GetHostByScreen(Screen.PrimaryScreen);

      var manager = NotificationHostManager.GetHostByVisual(this);
      foreach (AnchorPosition value in Enum.GetValues(typeof(AnchorPosition)))
      {
           manager.DisplayAsync(new SimpleNotification($"Test notification {value}."), value);
      }
}

press F11 at DisplayAsync

• now you enter SimpleNotifaction constructor

• shift F11 + F11 should enter DisplayAsync - it does not

• Only using F11 to enter DisplayAsync** - it does not work
  

Is this a known issue? SourceLink is pretty cool, but if debugging using F11/shift+F11 does not work that makes it rather useless.

Artifacts are available at https://ci.appveyor.com/project/taori/amusoft-ui-wpf/branch/dev/artifacts

[tmat]

This is not an issue in SourceLink, but rather it seems like a bug in the VS debugger stepping logic.

If you add the following line:

new NotificationHost(null, null);

at the beginning of the method and F11 on it, it will fetch the source file containing NotificationHost type. Then in that file you can place a breakpoint on line 34: EnsureBuildNotificationDisplayExists(position, presenter); and then stepping into DisplayAsync will hit that break point.

To figure out what's wrong with the stepping logic we need to look to the MoveNext method of the state machine generated for DisplayAsync. The method IL starts with the following instructions. ~ marks a hidden sequence point while - denotes a sequence point associates with user code. The debugger step into logic should skip the hidden sequence points and break at the first non-hidden sequence point, which is at IL_001a: ldloc.1.

.method /*06000149*/ private hidebysig newslot virtual final instance void  MoveNext() cil managed
{
 ~IL_0000:  ldarg.0
  IL_0001:  ldfld      int32 Amusoft.UI.WPF.Notifications.NotificationHost/*02000051*//'<DisplayAsync>d__10'/*02000064*/::'<>1__state' /* 04000089 */
  IL_0006:  stloc.0
  IL_0007:  ldarg.0
  IL_0008:  ldfld      class Amusoft.UI.WPF.Notifications.NotificationHost/*02000051*/ Amusoft.UI.WPF.Notifications.NotificationHost/*02000051*//'<DisplayAsync>d__10'/*02000064*/::'<>4__this' /* 0400008B */
  IL_000d:  stloc.1
  .try
  {
   ~IL_000e:  ldloc.0
    IL_000f:  brfalse    IL_0170
   ~IL_0014:  newobj     instance void Amusoft.UI.WPF.Notifications.NotificationHost/*02000051*//'<>c__DisplayClass10_0'/*02000063*/::.ctor() /* 06000147 */
    IL_0019:  stloc.2
   -IL_001a:  ldloc.1
    IL_001b:  call       instance class Amusoft.UI.WPF.Adorners.AnchorAdornerManager/*0200005D*/ Amusoft.UI.WPF.Notifications.NotificationHost/*02000051*/::get_Manager() /* 060000C5 */
    IL_0020:  ldarg.0
    IL_0021:  ldfld      valuetype Amusoft.UI.WPF.Notifications.AnchorPosition/*0200004F*/ Amusoft.UI.WPF.Notifications.NotificationHost/*02000051*//'<DisplayAsync>d__10'/*02000064*/::position /* 0400008C */
    IL_0026:  ldloca.s   V_3
    IL_0028:  callvirt   instance bool Amusoft.UI.WPF.Adorners.AnchorAdornerManager/*0200005D*/::TryGetPresenter(valuetype Amusoft.UI.WPF.Notifications.AnchorPosition/*0200004F*/,
                                                                                                                 class [PresentationFramework/*23000002*/]System.Windows.Controls.ContentPresenter/*01000041*/&) /* 0600012B */
    IL_002d:  brtrue.s   IL_004f

[tmat]

@chuckries Is this a known debugger issue?

[chuckries]

This is not known as far as I know. I think it may be related to optimized code, but I will dig in deeper. I will file a bug on debugger for this.

[chuckries]

Yes, this is definitely related to optimized code. Building the Amusoft.UI.WPF repo Debug at the commit for 0.2.5-alpha00112 and then trying this repro against it correctly steps into DisplayAsync. I will investigate why the debugger isn't stepping into the optimized code.

[tmat]

Turns out this is a bug in C# compiler: dotnet/roslyn#32573

[taori]

Great work. You guys are damn quick