React to Mono WebAssembly changes for 3.1 preview3

[SteveSandersonMS]

This is necessary when we receive the changes in dotnet/blazor#1923

Until then, this will fail on build.

[SteveSandersonMS]

I know this is not going to survive API review eventually, but it's the closest thing to what we already have. I don't want to design a new thing just as part of reacting to an external change.

[javiercn]

The biggest change in this PR is the removal of our own HttpClient handler in favor of one provided by Mono, is that the case?

I don't remember stuff about the MSBuild piece, but that might change in the future, so I think this is good.

Thanks for taking care of this!

[SteveSandersonMS]

The biggest change in this PR is the removal of our own HttpClient handler in favor of one provided by Mono, is that the case?

Yes. Mono has removed the ability to set a custom default HttpMessageHandler, which we were doing before. The default is now always the one in Mono's WebAssembly.Net.Http assembly. Overall this is a good thing because now other things like HttpClientFactory should start working as expected.

The main complication is that we don't expose any reference to Microsoft.AspNetCore.Blazor.Mono, as that is used during build only. Therefore there's no design-time reference to WebAssembly.Net.Http either, hence having to do all the reflection to set the default credentials options. I think it's fine since it's purely an internal implementation detail. Eventually we might want Microsoft.AspNetCore.Blazor to take a package dependency on WebAssembly.Net.Http but we can't do that today in any reasonable way because WebAssembly.Net.Http doesn't get published anywhere as a package.

[campersau]

So this fixes some of the HTTP streaming issues like #5586, #13329 ?
But we would have to enable streaming manually via reflection because of this mono/mono#17328 ?

[pranavkm]

Yes. Mono has removed the ability to set a custom default HttpMessageHandler, which we were doing before. The default is now always the one in Mono's WebAssembly.Net.Http assembly. Overall this is a good thing because now other things like HttpClientFactory should start working as expected.

FYI @anurse \ @BrennanConroy

[BrennanConroy]

The default is now always the one in Mono's WebAssembly.Net.Http assembly

Are you saying that new HttpClientHandler(); will just work now and use the one Mono provides?

[SteveSandersonMS]

Are you saying that new HttpClientHandler(); will just work now and use the one Mono provides?

I had thought that would be the case, but we just spoke with the Mono team today and apparently it is not. There is currently still a separate wasm-specific HTTP handler; the change is that it's provided by Mono now and not by Blazor.

We have asked for this design to be reconsidered because we do want things like new HttpClientHandler to just work, but there isn't an ETA on that yet.

@BrennanConroy You might also be interested to know that we're not far off having proper ClientWebSocket support in Mono WebAssembly, so the .NET SignalR client should be able to work on wasm soon. We're not there yet because currently you have to new up a completely different wasm-specific alternative to ClientWebSocket right now, but that's another thing we've asked to be changed.

[SteveSandersonMS]

@Pilchie Need approval for preview 3

[Pilchie]

Approved for 3.1.0-Preview3.

[SteveSandersonMS]

The changes here have been merged as part of #16685