more fixes for msquic packaging

[wfurt]

It seems like previous change was good enough get it to runtime and run tests but it was not good enough to make it the final product.
With this, I verified that msquic.dll is part of created dotnet-runtime-6.0.0-dev-win-x64.zip and I also run the msi installer and I check install shared directory.

We also crate aspnet transport package and I'm not sure if the native dll needs to be there since it is now part of the runtime. We can possibly re-visit this later if need to.

[ghost]

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

Issue Details

---

It seems like previous change was good enough get it to runtime and run tests but it was not good enough to make it the final product.
With this, I verified that msquic.dll is part of created dotnet-runtime-6.0.0-dev-win-x64.zip and I also run the msi installer and I check install shared directory.

We also crate aspnet transport package and I'm not sure if the native dll needs to be there since it is now part of the runtime. We can possibly re-visit this later if need to.

Author:	wfurt
Assignees:	wfurt
Labels:	area-System.Net.Quic
Milestone:	-

[safern]

LGTM

[ericstj]

We also crate aspnet transport package and I'm not sure if the native dll needs to be there since it is now part of the runtime. We can possibly re-visit this later if need to.

It doesn’t need to be there. You don’t need ASP.NET to know about this file in any way right? It’s an implementation detail of the assembly in the runtime.

[wfurt]

We also crate aspnet transport package and I'm not sure if the native dll needs to be there since it is now part of the runtime. We can possibly re-visit this later if need to.

It doesn’t need to be there. You don’t need ASP.NET to know about this file in any way right? It’s an implementation detail of the assembly in the runtime.

Currently the package has ref assembly but also System.Net.Quic.dll itself. I don't know how somebody would consume it without the native bits. But that may be just artifact of use trying to pass in the refs.

[ericstj]

Currently the package has ref assembly but also System.Net.Quic.dll itself.

That’s not right but they don’t consume it so it’s not a major issue, just cleanup.

[ManickaP]

Is this closing #52085 once again? Should we adjust the description then?

[jkoritzinsky]

I think we might have a problem with single-file host + msquic. Since msquic.dll isn't linked into the single file host statically, it needs to be included in the SingleFileHostIncludeFilename item group. However, that would mean that msquic.dll is outputted alongside the single file host for everyone who uses single file, which is a subpar experience since QUIC support is in preview.

[ericstj]

@jkoritzinsky what happens for System.IO.Compression.Native?

[jkoritzinsky]

System.IO.Compression.Native is statically linked into the single file host, so it doesn't need to ship alongside it.

In the CMake build script:

runtime/src/native/corehost/apphost/static/CMakeLists.txt

Line 120 in fa779e8

System.IO.Compression.Native-Static

[ericstj]

Interesting. Perhaps that's a separate issue for the networking team to peel off and address since this shouldn't make it any worse, right? Today msquic fails to load for all apps, after this change it will fail to load for single-file apps.

Some options to consider are:

1. Provide an msquic static lib and link that to the host.
2. Treat msquic as a SingleFileHostIncludeFilename and always make self contained apps bundle it.
3. Create some way (using build functionality, linker, etc) for it to be optionally included either by opt-in or detection of API usage.

[ManickaP]

Create some way (using build functionality, linker, etc) for it to be optionally included either by opt-in or detection of API usage.

We have that. If the msquic.dll is not present on the target machine, we just disable QUIC and by proxy HTTP/3.

[jkoritzinsky]

Yes, this can be future work. I just wanted to raise it before I forgot.

[ericstj]

We have that. If the msquic.dll is not present on the target machine, we just disable QUIC and by proxy HTTP/3.

I was talking about the reverse, where the build could decide when to include the dll in the customer's single file app. If there was a way for the customer (or the customer's app/project) to express "I want my single file app to have QUIC" rather than us say in our framework metadata that it must always be present.

[ManickaP]

We have an AppContext switch: System.Net.SocketsHttpHandler.Http3Support would that be enough?

This PR: #55332

[wfurt]

I'm glad you brought it up @jkoritzinsky and I think this should be future work. Quic/H3 is preview feature for 6.0 so I'm not sure if we should pollute the single file with something that is unlikely to be used. As @ericstj mentioned it would be great if this is something the project can control.
Also this is specific to Windows. For Linux/macOS we expect user to provide msquic as system dependency.

[ManickaP]

Yes, this can be future work. I just wanted to raise it before I forgot.

Tracking in #55639

[wfurt]

Mono build failure looks irrelevant.