How do you debug C# code executed within the worker?

[ivan-prodanov]

Hi,

I'm using your blazorworker.js to execute C# code from javascript in a worker (without the rest of the functionality, e.g no need to use callbacks to C#, just javascript main thread <-> C# (through worker) <-> javascript. Using this approach, I noticed there's no way to debug the C# code executed by the worker itself apart from rewiring Console.WriteLine to the browser console.

I was curious to know, do you know any way to debug the C# code using the debugger in VS?

[Tewr]

Hello. I have not looked into that but I'd not expect it it to work out of the box in any trivial way. That said, I have skimmed over a few of the flags that enable debugging in the dotnet script, and it might not be that far off...

[ivan-prodanov]

@Tewr could you help me out here - where did you find these flags?

[Tewr]

I'm sure I stumbled over it when reading the source code of the mono wrapper and the blazor init code. When I get the time I can look into it, but I wonder if it wasn't the second argument here:

BlazorWorker/src/BlazorWorker/BlazorWorker.js

Line 126 in eef6220

load_runtime(appBinDirName, 0);

[ivan-prodanov]

@Tewr that's correct. I found the check inside mono_wasm_load_runtime:
https://github.com/dotnet/runtime/blob/85cb1dff6546319c4e5d235f079b4e6147892381/src/mono/wasm/runtime/driver.c#L521

And the code of mono_wasm_enable_debugging:
https://github.com/dotnet/runtime/blob/29ec808be2b105d0b11b5a0632b6adda980a9306/src/mono/mono/mini/mini-wasm-debugger.c#L454

Unfortunately, I don't know how to get this working.

[Tewr]

I think that with a certain investment it might be possible to debug the c# inside chrome. To get actual c# debugging in visual studio I'm guessing the price is a lot higher, unless someone from ms or mono would provide a full write-up on how they did it for blazor

[ivan-prodanov]

@Tewr I did it. Debugging in DevTools works with slight modifications but it's just very limited experience. I managed to make it work in VS by modifying the debugging proxy in Mono. That pretty much delivers the C# wasm experience with workers that I was looking for (without needing to use Blazor).

[Tewr]

@ivan-prodanov That is awesome news. It would be useful for the consumers of this component if you could manage to write a small guide on how to achieve this - I am guessing I would have to detect debugging and enable the flag in the library as well?

[ivan-prodanov]

More work is needed to make this ready for general use in Blazor. Currently hitting F5 in VS/code on a blazor project connects the debugger in VS/code with a proxy between Chrome and VS/code. This proxy has to be modified in order to support workers, which in itself is fine, however modifying VS/code to use the custom proxy instead of the one provided by Microsoft is non-trivial for blazor projects. It's fine for plugging it in a e.g react/angular/non-blazor project because it's not blazor, it does not use any proxy by default. I'm guessing some serious modifications have to be made in the way blazor projects are started, which I will leave to you as I'm not interested in Blazor.

As for the details, I will soon publish a package that allows using C# in react apps with debugging experience and workers.

[Robulane]

@ivan-prodanov , how did you manage to run the debugger on web worker? Can you please share the package that you wanted to create?

The issue I am getting is that Mono's debugger sends the commands to execute in Chrome developer tools and these commands are got executed on the main thread and not on the worker.

[Matheos96]

Old thread but stumbled upon this today myself. Implementing Blazorworker into our solution and found that regular .NET breakpoints that would occur at some point in the code, past the creation of a worker (or was it BackgroundService...) will never be hit. I guess this is hard nut to crack but really would be a nice thing to have as all breakpoints past making the workers are now completely unusuable

[ivan-prodanov]

@Robulane @Matheos96 Guys I don't quite remember what i changed in the BrowserDebugProxy but basically i took MS' code and debugged the debug proxy and found out that debugging information coming from other threads is not sent to the debugger correctly, a small change had to be done but i dont remember where exactly. You can see the modified code which works with debugging multiple threads though:
https://github.com/ivan-prodanov/Wasm/tree/main/net/BrowserDebugProxy