Tewr / BlazorWorker

Library for creating DotNet Web Worker threads/multithreading in Client side Blazor
MIT License
377 stars 34 forks source link

BlazorWorker breaking the debugger #116

Open marcussacana opened 2 weeks ago

marcussacana commented 2 weeks ago

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>();

devenv_UPmrRtwGbx 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 commented 2 weeks ago

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 commented 2 weeks ago

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.