[Debugging] Breakpoints in .razor files, which are not in the @code block won't bind

[mkArtakMSFT]

From @mkArtakMSFT on Thursday, March 26, 2020 7:09:38 PM

Using the latest VS preview (16.6 Preview 3) release with the latest Blazor bits (3.2-preview3):

Copied from original issue: dotnet/aspnetcore#20200

[mkArtakMSFT]

From @mihaimyh on Thursday, March 26, 2020 9:48:24 PM

Neither those in a "code-behind" class, like FetchData.razor.cs.

[mkArtakMSFT]

/cc @SteveSandersonMS

[mihaimyh]

I am not 100% sure but also debugging razor class libraries is not working. Until now I was not able to debug anything WASM related using latest WebAssembly 3.2.0 Preview 3, but I will try and see if this is just something on my side.

[lewing]

Breakpoints on the loop work fine, I'm not familiar enough with how razor sequence points map to the runtime to understand why this is failing

/cc @vargaz

[vargaz]

Sequence point -> File/line mapping is picked up from the .pdb files. It doesn't matter whenever it is a .cs file or some other source file.

[lewing]

@thaystg can you look into what is going on here and why we can't hit breakpoints in the body of the razor loop.

[thaystg]

The problem is in rzc.dll, which is responsible for generating the .g.cs file from razor file.
I used this file as an example of razor file:

https://gist.github.com/thaystg/be141b64b68c21701d796e19b4c868c6.js

Without any change in rzc.dll the generated file is like this:

__builder.AddContent(3, 
#nullable restore
#line 6 "/Users/thaysgrazia/AspNetCore/src/Components/Blazor/testassets/StandaloneApp/Pages/Counter.razor"
  currentCount == currentCount + 1

#line default
#line hidden
#nullable disable
            );

And it doesn't stop on line 6.
When I changed the rzc.dll to generate this the breakpoint works:

__builder.AddContent(3, 
#nullable restore
#line 6 "/Users/thaysgrazia/AspNetCore/src/Components/Blazor/testassets/StandaloneApp/Pages/Counter.razor"
currentCount == currentCount  + 1);
__builder.AddMarkupContent(4, "\n\n");
#nullable restore

I'm not sure exactly why, but the problem is with the generated file, I think that it's because the #line 6 and the #line hidden is in the same command, so the csc consider that the line is hidden and is not creating the right pdb, the line 6 is created as a hidden line, and that is the reason why the breakpoint doesn't stop.

[lewing]

Does #19487 help?

[thaystg]

No, Larry, because ALL hidden breakpoints has line number= 0xfeefee, so we don't have the information of the right line number.

[lewing]

cc @SteveSandersonMS

[SteveSandersonMS]

@ajaybhargavb @NTaylorMullen Does this sound like any known issue with Razor line number generation? Would you have expected this to work?

[NTaylorMullen]

@ajaybhargavb @NTaylorMullen Does this sound like any known issue with Razor line number generation? Would you have expected this to work?

Definitely would have expected this to work. Razor has been generating this way for a longggg time and we haven't changed that behavior for close to a year. We purposefully are adding the line hidden directives to ensure that you don't debug into non-visible / non-C# code.

[NTaylorMullen]

Oh and the only "known" issue in Razor line pragma generation is that we can't specify columns so occasionally things are misaligned; however, Razor's been that way since day 0 😄

[lewing]

@NTaylorMullen this is an entirely new debugger we're just trying to understand how to interpret what we see in the pdb

[lewing]

@thaystg can you see if your fixes to the sequence point choosing has resolved this?

[thaystg]

Yes, I'll check.

[thaystg]

No, Larry, it doesn't fix.
I tested this:

@page "/counter"

<h1>Counter</h1>

<p>Current count: @currentCount</p>
<p>Current name: @teste.getName()</p> //inserted the breakpoint here

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
	private Thays teste = new Thays();
	private int currentCount = 0;

	private void IncrementCount()
	{
		currentCount++;
	}
}

And as I expect it does not stop even when running on Blazor Server, which is a completely different debugger engine, because the cs file is generated in a way that the breakpoints are hidden, so it's impossible to stop, for wasm debugger engine and also for Blazor Server debugger engine.

[NTaylorMullen]

I think this has to be fixed on the Roslyn side. It's tracked in two locations:

• Cannot hit breakpoints in parameter mapped locations
• Expand #line to support columns

[lewing]

I'm going to close this mono/mono issue then since we're not expecting to do any work here and the issue isn't wasm specific