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.