BlazorWorker breaking the debugger

[marcussacana]

I spent a time trying to solve a problem where the debugger just ignore all breakpoints after my app initializes, but after step the whole initialization, I've found that the debugger does not break (or step) after this line:

await Worker.CreateBackgroundServiceAsync<T>();

The debugger output print this as well:

The 0x3f2c thread was closed with code 0 (0x0).
The thread '.NET TP Worker' (0x2ec8) was closed with code 0 (0x0).
The thread '.NET TP Worker' (0x20a4) was closed with code 0 (0x0).
The thread '.NET TP Worker' (0x4454) was closed with code 0 (0x0).
The thread '.NET TP Worker' (0x49d8) was closed with code 0 (0x0).
The thread '.NET TP Worker' (0x61d4) was closed with code 0 (0x0).
The thread '.NET TP Worker' (0x802c) was closed with code 0 (0x0).
The thread '.NET TP Worker' (0x4B34) was closed with code 0 (0x0).
The thread 'sermone' (0x0) was closed with code 0 (0x0).
The "JavaScript Decoration Adapter: localhost: 5004" program was closed with code 4294967295 (0xfffffff).
The thread 'Service Worker http://localhost:5004/service-worker.js' (0x1) was closed with code 0 (0x0).
The "Service-Worker.js" program was closed with code 4294967295 (0xfffffff).
Thread 0x2 was closed with code 0 (0x0).
The program "04099907-0717-4d89-84d2-B23CC16d7EEE" was closed with code 4294967295 (0xfffffff).
Browser connection failure, will be repeated: Connection Closed

I was doing a upgrade from the .NET 5 to .NET 8 this may be a problem that happened due the upgrade, but I would appreciate if you know if there are something that can be done to solve this issue.

Currently I can debug my app by just including #if !DEBUG in worker related features.

[Tewr]

Hello,

The debugging experience has always been very limited. It's possible that creating a new process while attached somehow breaks the debugger connection, like a conflict or something.

I don't have any quick fix for this problem unfortunately.

I know there is a debugger flag for the the new dotnet process in there somewhere, it may have some impact and indeed there may be differences between runtime behavior for this kind of stuff.

So this worked for you in .net 5? Could be an interesting starting point. However the init code is wildly different starting .net 7

[marcussacana]

This project it was pretty lost in space, I didn't used with .NET 5 for a long time, but I belive it worked before the debugger in the main process at least (nothing in worker process) After this upgrade I faced this issue. What if the blazor worker let I choose a subdir as root for the .net related files, then I can let a release build inside that folder. I think with worker using a release build should not disturb the debugger. But not sure, just a quick idea.

[Tewr]

I haven't found any workaround.

However I have found this issue which is surely related: https://github.com/dotnet/runtime/issues/98208

[marcussacana]

Yeah, pretty likely to be the same problem, thank you, I will keep an eye in that issue.

[FreyLuis]

I did not yet have time to try it out, but I came across this in the docs:

<!-- disable debugger -->
<WasmDebugLevel>0</WasmDebugLevel>

That same flag can be set via js: https://github.com/dotnet/runtime/blob/main/src%2Fnative%2Fcorehost%2Fbrowserhost%2Floader%2Fhost-builder.ts#L54

Could that be the flag you where looking for?