Aspnetcore: Enable mono.wasm bindings in Blazor

[danroth27]

Moving to the mono.wasm bindings should enable support for WebSockets, HttpClient without addition code on our side, etc.

The work involved appears to be:

• Taking a mono build with the bindings turned on
• Adding a couple extra assemblies
• Removing our code where we set up our custom HttpClient handler
• Potentially change some of our JS-side code to change how Mono is started up.

[dazinator]

Is BrowserHttpMessageHandler no longer needed in latest preview bits then - i.e can you just use new HttpClient() or is there a replacement handler? Reason I ask is because in my Blazor client app (preview5) I am trying to configure my own HttpClient, and I can't find the type: BrowserHttpMessageHandler to pass to the constructor.

[danroth27]

@dazinator I believe we currently use some Mono magic to swap in our WebAssemblyHttpMessageHandler for Blazor apps. This issue tracks switching to use the built-in Mono handler as well as some other Mono provided bindings.

[LunicLynx]

@danroth27 I'm really looking forward to this!

In the meantime one thing though. Why are changes like this made?
https://github.com/aspnet/AspNetCore/commit/04c3192d3cec396a9f2343fb5407d6777349b9df#diff-db0ad15f21551ab0bd6aa7fd83004a97
This broke the existing BlazorSignalR implementation. I totally get the reasoning in hiding implementation details, but for lack of a better alternative this change should not have been made. Also i think it would be useful if there is documentation to replace the transport layer in signalR with minimal overhead.

[danroth27]

@LunicLynx The types in the *.Internal namespaces were never intended for public consumption, so in 3.0 we decide to update them to be truly internal. You can read more details about this change in the announcement here: https://github.com/aspnet/Announcements/issues/377.

As for replacing the SignalR transport layer, could you please open a new issue for that so that we can get the SignalR folks involved? This feedback is valuable as we are trying to react to areas where we made something internal that was important and useful.

/cc: @anurse @bradygaster

[anurse]

All types in .Internal namespaces were not supported and not protected against breaking changes. We didn't think this was a useful and clear message though, so they were made internal. If you need functionality that was removed, I'd agree with @danroth27 here, file a bug and we'll talk about a public officially-supported way we can help you achieve your goal.

[hkusulja]

I am also interested to use Blazor client model (WASM) to use SignalR (websockets) to connect to the SignarlR server (asp.net core server-backend)

Any progress on this?

[danroth27]

Nothing new to share yet on our side for a Blazor WebAssembly compatible SignalR client. For now, I would suggest using one of the existing SignalR clients from the community:

• https://github.com/BlazorExtensions/SignalR
• https://github.com/csnewman/BlazorSignalR

[mkArtakMSFT]

This is already done by @SteveSandersonMS