[HTTP/3] Support Single-file and NativeAOT on Windows

[karelz]

HTTP/3 should be supported also in Single-file and NativeAOT scenario on Windows.

Linux is simple as msquic is "part of OS" - external package that is prereq for HTTP/3 to work.
On Windows, we build and include msquic.dll as part of .NET Runtime.

@vitek-karas can point us to what needs to happen to make it work.
cc @jkotas

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

HTTP/3 should be supported also in Single-file scenario on Windows.

Linux is simple as msquic is "part of OS" - external package that is prereq for HTTP/3 to work.
On Windows, we build and include msquic.dll as part of .NET Runtime.

@vitek-karas can point us to what needs to happen to make it work.
cc @jkotas

Author:	karelz
Assignees:	-
Labels:	enhancement, area-System.Net.Http
Milestone:	8.0.0

[karelz]

Triage: We discussed with @vitek-karas that such work should be part of 8.0 -- it is too late for 7.0 and the usage of HTTP/3 is not that much widespread yet.
Moreover, there is workaround (which we can document on demand) to copy msquic.dll next to Single-file (while not perfect, it is at least functional).

[vitek-karas]

@VSadov should know the technical details, but high level:

• msquic needs to be statically linked into the singlefilehost.exe during our build
• The native entry points which msquic exposes and are used by managed code need to be "marked" as internal, so that interop redirects them into the exe (and won't try to load msquic.dll
• The managed code which uses msquic might need changes - the above will work without changes if we use simple PInvokes (DllImport) but if there's other usage we might need to make some tweaks

There's obviously a size aspect to all of this - as this will make the single-file host cca 500KB bigger - for everybody.

[teo-tsirpanis]

I wonder if we could create bespoke single-file hosts that link to custom static libraries at publish-time. The apps that don't use HttpClient won't have to bear the burden of half a megabyte of code they won't use, and these that do use it but don't need HTTP/3 would be able to remove support for it with a feature switch, and other libraries could use it to bundle their own native dependencies. I think something similar is done by Blazor WebAssembly to reduce size.

Of course it would be an optional feature since it would need additional dependencies such as a native linker, and the default would still be a single-file host that links everything we might need.

[vitek-karas]

So far we've been trying to avoid dependency on platform linker for these scenarios. I think we might be able to do this for the NativeAOT version of this problem, since that one already has a dependency on platform linker.

[jkotas]

msquic needs to be statically linked into the singlefilehost.exe during our build

This requires to either (1) msquic repo to produce .lib file that gets statically linked into the singlefilehost in dotnet/runtme or (2) vendor msquic sources into dotnet/runtime and build it there for static linking into the singlefilehost.

Once msquic is statically linked into the singlefilehost, the rest is trivial.

[karelz]

@jkotas we build Windows in our fork https://github.com/dotnet/msquic -- that's how Windows DLLs are built for .NET Runtime product.
I assume that building and publishing .lib should not be a big problem in the same repo. cc @wfurt

[jkotas]

Yes, it is certainly doable. If the .lib is built in one repo and consumed in second repo, there are details you need to be careful about - like making sure that the compiler versions and compiler options are the same or at least compatible between the repos. It may be challenging to manage at times when the compilers are getting upgraded.

[nibanks]

Another, completely orthogonal path could be that we align the Windows model with Linux, and we ship MsQuic via a package manager (winget), and .NET doesn't package msquic at all. .NET already has the code to opportunistically load msquic when available.

The obvious downside with this approach is that you will always require an additional step, even in the single-file scenarios, to install the msquic dependency (if not already). So I'm not quite sure if you'd consider this solving the single-file problem or not. Generally, this seems to be deemed an acceptable model on Linux, but is not commonplace on Windows, and I suspect would receive push back. Just a thought though....