Unbound breakpoints when debugging in Blazor Webassembly when using certain attributes/classes

Viewed 3410

I'm developing a modular blazor application (5.0.2) using VS 2019 (16.8.4), which is structured as follows:

  • a "Main" Solution, which consists of

    • RCL
    • Wasm project to startup the application
  • several "Sub" solutions which reference the Main RCL (Base components, etc) which consist of

    • .net5 libraries (Models, Web-service access, etc)
    • RCL with components, referencing the .net5 libraries (via project reference)

All projects have a post-build event to copy the DLL and PDB files to a certain path, e.g. D:\TMP. The SubSolution references the MainRCL library via this path. The Main Wasm project references the SubRCL library also via this path (for adding services at startup/Program.cs).

The MainRCL does not have a reference to SubRCL (components are rendered via reflection/BuildRenderTree() according to configurable UI definition).

Debugging the Main Solution worked perfectly (IIS Express/Application Debugging). Then I tried to debug the SubModules -> I started debugging from the MainSolution and opened files from the SubModules projects in this VS instance.

At some libraries, debugging was working, but not for the SubRCL ("Unbound Breakpoint"). Then I was able to reproduce the (very strange) issue with sample solutions:

The "MainRCL" provides 2 Attributes:

[AttributeUsage(AttributeTargets.Class)]
public sealed class TestNoEnumAttribute : Attribute
{
    public string Name { get; set; }

    public string Mode { get; set; }

    public TestNoEnumAttribute(string name, string mode)
    {
        Name = name;
        Mode = mode;
    }
}

[AttributeUsage(AttributeTargets.Class)]
public sealed class TestEnumAttribute : Attribute
{
    public string Name { get; set; }
   
    public EventExecutionMode Mode { get; set; }
  
    public TestEnumAttribute(string name, EventExecutionMode mode)
    {
        Name = name;
        Mode = mode;
    }
}

public enum EventExecutionMode
{
    AutomaticAll = 0,
    ManualConfiguration = 2
}

The SubRCL uses these attributes at a test-method:

[TestNoEnum("Test", "EventExecutionMode.ManualConfiguration")]
//[TestEnum("Test", EventExecutionMode.ManualConfiguration)]
public class Module1Test
{
    public int IncreaseNum(int num)
    {
        var x = new Part1();
        var part1Num = x.DoStuff(num);
        var newNum = part1Num + 1;
        return newNum;
    }
}

The class "Part1()" which is called, is located at another library of the SubSolution

The breakpoint at the "DoStuff()" method in Part1 class is always hit (in separate .net5 library). The breakpoint at the "IncreaseNum()" method is only called when the [TestEnum] attribute is NOT used. As soon as the [TestEnum] attribute is used, there is an "Unbound Breapoint"; the breakpoint in "DoStuff()" method in another library is still hit.

Then I tried to "add existing project" to SubSolution and added the MainWasm project and started debugging directly from SubSolution -> same behavior.

Is there anything I oversee (e.g. regarding DLL-references or PDB file copy)?

This is already my second approach of trying to debug these modular-structured solutions - first I tried to debug via IIS (How to debug Blazor Webassembly on IIS with VS by attaching to Chrome?), but this was also not successful.

2 Answers

Found out there is an issue with debugging when using attribues with enum parameters:

https://github.com/dotnet/aspnetcore/issues/25380

-> I replaced the enum parameters and debugging is working fine now - Didn't get any feedback when this will be fixed so far

I had the same issue with my Blazor WASM not able to be debugged in VS due to 'Unbound breakpoint'. I have multiple projects running under the same solution and while initially the debugging worked for the WASM, it stopped after a while.

Eventually I was able to find a work around by waiting until all projects loaded and then I could disable the 'Unbound' breakpoint and re-select it. It then worked as expected.

It's not an ideal solution (especially if you have multiple breakpoints while troubleshooting) but it is workable.

Related