.NET Web Worker template cleanup

[danroth27]

Some cleanup items for the .NET Web Worker template:

• Remove the license headers from generated template files
• Remove or condense the heavy XML doc comments on WebWorkerClient
• The DisposeAsync method in WebWorkerClient catches a JSDisconnectedException with the comment "Circuit disconnected, worker is already gone", but circuits are specific to Blazor Server-
• Consider adding an initialization timeout for the worker in case the runtime fails to load silently.
• The parseIfJson logic in dotnet-web-worker-client.js seems potentially problematic if a worker method returns a string that happens to look like JSON. Consider either always deserializing or never parsing.
• Consider adding an InvokeVoidAsync method to WebWorkerClient

[github-actions]

Triage Summary

Area: area-blazor — The issue concerns the .NET Web Worker template and its WebWorkerClient class, which uses JSDisconnectedException (from Microsoft.JSInterop) and patterns from Blazor's JS interop layer. The template lives under the Blazor/Components area.

Type: feature-request — This is a set of cleanup and improvement items for an existing template: code quality fixes (license headers, doc comments), a potential correctness fix (wrong exception type), and new API additions (InvokeVoidAsync). Overall it represents enhancements rather than a broken behavior.

Potential Duplicates

None found.

Notes

• The JSDisconnectedException item is worth calling out: it's caught with a comment saying "Circuit disconnected, worker is already gone", but circuits are a Blazor Server concept — on WebAssembly there are no circuits. This item may be a minor bug within the cleanup scope, but it's correctly tracked here.
• The parseIfJson concern in dotnet-web-worker-client.js could have correctness implications if a worker method legitimately returns a JSON-like string — worth a concrete decision (always deserialize or never auto-parse).

Generated by Issue Triage Agent for dotnet/aspnetcore for issue #65937 · ◷

[ilonatommy]

• Remove or condense the heavy XML doc comments on WebWorkerClient

What exactly? The idea was that we will ship the setup instructions in xml comments. How else do we point users to manual for that library? Should we add link to docs instead? We don't have any other templates that would be of similar complexity so it's natural they don't have so complex xml docs.

Temporarily, I will adopt a RazorClassLibrary-like approach in the initial fix for this issue (no summary, no remarks) and you could tell me if you would like to see more or less details than that.

[ilonatommy]

• The parseIfJson logic in dotnet-web-worker-client.js seems potentially problematic if a worker method returns a string that happens to look like JSON. Consider either always deserializing or never parsing.

The point of using Blazor interop in the template was to make it work out of the box. If we choose "never parsing" then we would push complexity onto the users - they would have to deserialize manually in C#. Going towards "always parsing" makes some scenarios invalid, you won't be able to return plain strings from their exported methods, they would need additional manual JsonSerializer.Serialize call.
I would rather go towards more complex parsing so that we avoid a situation when a string is parsed as a valid JSON even though it was not meant to. We can check if after JSON parsing we got a primitive or not. We should return the result only in the latter case.

[danroth27]

The point of using Blazor interop in the template was to make it work out of the box. If we choose "never parsing" then we would push complexity onto the users - they would have to deserialize manually in C#. Going towards "always parsing" makes some scenarios invalid, you won't be able to return plain strings from their exported methods, they would need additional manual JsonSerializer.Serialize call. I would rather go towards more complex parsing so that we avoid a situation when a string is parsed as a valid JSON even though it was not meant to. We can check if after JSON parsing we got a primitive or not. We should return the result only in the latter case.

It seems like this special handling of deserialization of return values creates some confusing inconsistencies. We don't handle serializing return values from the [JSExport] method, correct? So, why would we handle deserializing them? Also, what about the input arguments? Don't [JSExport] methods only accept primitive argument values? It seems cleaner to document for both args and return values that [JSExport] only deals with primitive types. Any serialization/deserialization is then up to the user to handle.