7

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.

4 Answers 4

6

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

Sign up to request clarification or add additional context in comments.

4 Comments

HOLY COW. First you saved my life. (I wish I could give you more votes at my own expense. :)) Secondly how on earth did you figure out this is what it was? It is truly a needle in a haystack problem. Thirdly what a bizarre and stupid bug and annoying that MS shows no interest in fixing it. Not even an Exception or anything. More evidence Blazor is still not ready for primetime. Anyway THANK YOU
Thanks, I'm glad this helps someone else, it took me about 7 days.. tried several different approaches, then I created a new "submodule" from scratch and copied the source code class by class (we are migrating a Silverlight application), and checked if the debugger is still working - until I found the reason.. So I just had to change the enum to a static class with int-constants, so there wasn't much source code adaption needed.. IMHO Blazor Wasm is already good to use, and VS/debugging integration is getting better and better - and I believe .NET6 will also bring Blazor to a new level
Wow. That is dedication. Kudos. And I hope you're right about Blazor. Thanks again!
FWIW, this debugger problem is fixed in .NET 6.0.0-preview.7.21378.6 and VS 2022 Preview 3.1.
0

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.

Comments

0

I had this problem in .NET 6 and Visual Studio 2022.

I made a codebehind-file component.razor.cs but I also had code in the razor-file itself. Moving the code to the codebehind-file solved the issue and enabled the breakpoints.

1 Comment

This may sound kinda stupid, but i solved the issue, by cutting and re-pasting the code. I just selected the piece of code, that was not being hit by the breakpoint and then just pasting it back. I understand that this solution is not exactly related with the original question, hence i m adding a mere comment.
0

I had this issue when I had DebugType set to Full in my Directory.Build.props file. After I removed the line, everything started to work.

<DebugType>Full</DebugType> 

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.