Blazor Wasm: VS Code debug adapter does not parse Razor Class Library

[zbecknell]

I've been fighting with this for a couple of days trying to get our decently complicated solution to hit a breakpoint in our Blazor components.

This gist is the output from vscode-debugadapter.json using "trace": true in launch.json.

https://gist.github.com/zbecknell/a3647dfc7818695c1be7722572307e10

I can't debug from VS either, but thankfully I can do some snooping easier with VS Code.

The Razor Class Library is Care.UI.dll. I can see it listed under the Runtime.consoleAPICalled table, but no scripts are ever parsed from the library. I know there's not much to go on... I tried to create a reproduction project but so far haven't been able to break debugging! I'm hoping the gist provides some hints to experts in the debug adapter.

Despite not being able to reproduce this (yet) with a project, I'll include the solution I did set up, which has a similar structure to the full project:

https://github.com/zbecknell/HostedRclDebug

What I need to figure out is how to instruct the debugger to parse my Care.UI.dll project, as it seems to completely ignore it. My .csproj for the example UI project and my full project are practically the same. I'm also able to debug standard class libraries referenced by Care.UI.dll triggered by UI actions (Care.Typescript.dll being an example).

Let me know if there's any more information that might be helpful. In the meantime, after a bit of a break, I'll continue trying to break a reproduction repo.

[zbecknell]

Another detail that comes to mind: earlier I tried moving all my .razor files to my Client project, thinking it may be the RCL that was the problem, but in fact classes in my Client project went from being debuggable to non-debuggable -- so there's actually something to do with the compilation of my .razor files that causes the problem. I'll work more today on reproducing this in my repro repo.

[mkArtakMSFT]

Thanks for contacting us.
@captainsafia adding this to the rest of your debug adapter related issues for consideration.

[captainsafia]

@zbecknell Can you try using the following launch configuration for the coreclr type?

{
	name: '.NET Core Launch (Blazor Hosted)',
	type: 'coreclr',
	request: 'launch',
	preLaunchTask: 'build',
	program: "The path to the HostedRCL.Server.dll under the build target for your framework config",
	args: [],
	cwd: "The directory where your Server project is",
}

[zbecknell]

Thanks for the suggestion, @captainsafia! I updated my launch configuration, but unfortunately I still can't hit a breakpoint. Here is an updated trace output:

https://gist.github.com/zbecknell/55d3c862eba5007d006ff1f836ebf916

Now Care.UI.dll only appears twice. I confirmed I can still debug a different project (Care.TypeScript.dll). One difference that was encouraging was that the breakpoint remained red and filled in rather than greying out, so I thought it might work:

[zbecknell]

@captainsafia, we host our code on Azure DevOps, would it be helpful to have access to the repository to see if you can spot any issues there? We can invite you to view the project if this would be helpful (I know you're flying somewhat blind right now).

[captainsafia]

@zbecknell If anything, I suspect that the issue has more to do with how the launch configuration is set than the code itself. It's likely unable to resolve the location of these sources. it does appear that the Care.UI.dll and its debugging assets are loaded correctly and nothing seems awary with the setBreakpoints DAP messages (which explains why they are not unbounded like you pointed out above).

Do you mind also sharing your full launch.json file?

[zbecknell]

@captainsafia I invited you to a private repository with launch.json as well as relevant project files and a tree structure. Let me know if anything else would be helpful.

[captainsafia]

I've been spending the past few days working on shipping the new blazorwasm debug type so I haven't had the chance to look at this.

We've been tracking down a few issues that come up related to our DebugProxy so it might be worthwhile to investigate if the issue occurs there.

Does this by chance work in VS? There's some subtle distinctions between the debugging setup in both IDEs that might help us figure out the issue.

[zbecknell]

This does not work in Visual Studio either. The behavior is the same: I CAN hit a breakpoint in a regular library with no Razor files but just cannot hit any breakpoints in Razor files.

In the sample project, for example, I can hit breakpoints in my Client project but not in my UI project. I actually tried moving my UI files back to Client at one point and debugging actually broke in that project too. I know I need to work on getting the actual reproduction happening, but have been quite busy with other things lately. I may be able to get to it later this week.

[captainsafia]

Thanks for checking! We recently fixed a bug in our package that disabled us from collecting logs on the debugger.

Can you follow the instructions here to patch this bug and share the logs that you get?

Let me know if you have any questions about the instructions above.

[zbecknell]

Thanks for the instructions @captainsafia.

Here is the output with logging turned on:

https://gist.github.com/zbecknell/a4f43e6dc3e8aea295f68599cb33b7bd

We now have clear indication of the attempt and failure to load the UI project:

But I don't see any reason why it shouldn't load it. All the references are present and able to be reached at the URLs mentioned (e.g. https://localhost:5001/_framework/_bin/Care.UI.dll).

I hope there's a clue in here for you.

[captainsafia]

@zbecknell Sorry for the delay on this! Can you repro this issue in the 5.0-preview7 release of Blazor WASM?

[zbecknell]

I'll let you know when I resolve a new build error and am able to test:

obj\Debug\net5.0\browser-wasm\Care.Client.MvcApplicationPartsAssemblyInfo.cs(13,54): error CS0234: The type or namespace name 'ApplicationPartAttributeAttribute' does not exist in the namespace 'Microsoft.AspNetCore.Mvc.ApplicationParts' (are you missing an assembly reference?) [C:\Care\src\Care.Client\Care.Client.csproj] 

For whatever reason this {ProjectName}.MvcPartsAssemblyInfo.cs gets generated with the following content:

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

using System;
using System.Reflection;

[assembly: Microsoft.AspNetCore.Mvc.ApplicationParts.ApplicationPartAttribute("Care.Shared")]
[assembly: Microsoft.AspNetCore.Mvc.ApplicationParts.ApplicationPartAttribute("Care.UI")]

// Generated by the MSBuild WriteCodeFragment class.

I haven't created an issue for this yet, but may need to unless I can figure it out soon.

[zbecknell]

Closing this as I've found the specific cause of debugging being broken in my project: #25380.