1

I try do debug a blazor webassembly app, that references a shared project named Test.Shared. I've been trying to set breakpoints in that projects code but nothing helped - breakpoints just aren't hit.

When I'm trying to set a breakpoint outside in the calling code and then step into "Test.Shared" source - it just seems to go step by step through the underlying code (I have to hit "step forward" multiple times before it proceeds the debugging to the next line, and the number of hits changes when I reduce/increase the number of lines in the underlying method code) but its not displayed in the debugger window.

So, after some investigation, I figured out that I can make the debugger work when I throw away all the code from the Test.Shared and leave only one simple test static method. Based on this fact I guess there is some specific type of C# code that causes the whole containing library to be invalid for debugging. Any suggestions what this code type might be?

The environment I use:

  1. Visual Studio Enterprise 2019 16.6.2
  2. NET Standard 2.1 as a target platform for both Blazor app and shared library
  3. NET Core 3.1 as a target platform for the hosting web app that serves webassembly app packages
  4. Microsoft.Components.WebAssembly 3.2.0
Sini4ka
  • 33
  • 7
  • "[that] there is some specific type of C# code that causes the whole containing library to be invalid for debugging" : no. – H H Jun 22 '20 at 07:42
  • What you describe sounds like the debugger can't find the source code or symbol files. So some problem in your build and reference setup. – H H Jun 22 '20 at 07:43
  • @HenkHolterman, yes, the debugger can't find souce code/symbol files - that's correct. But I don't think something is wrong with build/refrence setup, cuz the problem is fixed after eliminating a PART of source code – Sini4ka Jun 22 '20 at 09:40
  • Possibly a duplicate of [Unbound breakpoints when debugging in Blazor Webassembly when using certain attributes/classes](https://stackoverflow.com/q/65720816/3744182). – dbc May 09 '21 at 05:19

1 Answers1

0

The issue is with having attributes that have enum values inside of them. Many people are having this problem and it's better explained in Blazor Wasm: debugging broken when referencing @attribute with enum contructor argument #25380 by zbecknell:

Here's a simple repro project: https://github.com/zbecknell/Undebuggable.

See Counter.razor:4 for the line that breaks debugging for the project:

@* The following line breaks debugging for the project, no matter how long you wait *@
@attribute [BadAttribute(BadEnum.Default)]
dbc
  • 104,963
  • 20
  • 228
  • 340
Max
  • 46
  • 1
  • 5