Open marcussacana opened 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
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.
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:
The debugger output print this as well:
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.