Support Windows 10 for System.Net.Quic

[StephenCleary]

I would love to see Win10 support added to System.Net.Quic OOTB.

I can see this happening one of two ways:

1. The SChannel updates in Win11 can be backported to Win10 and released to that OS.
2. msquic can use OpenSSL by default on all platforms rather than using SChannel on some.

Regardless of the solution specifics, my goal is including Win10 support in the default System.Net.Quic NuGet.

[dotnet-policy-service]

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

[rzikm]

The SChannel updates in Win11 can be backported to Win10 and released to that OS.

That is a request that would have to go to SChannel team, but I don't think they will be willing to backport these changes.

msquic can use OpenSSL by default on all platforms rather than using SChannel on some.

MsQuic team already publishes both SChannel and OpenSSL-based build of MsQuic, while not "out of the box", you can run System.Net.Quic on Windows 10 already by replacing the msquic.dll in the published application with the OpenSSL-based one.

I raised a (no-merge) PR which replaces the msquic used by runtime by OpenSSL-MsQuic #101849. The tests are all passing except one test which tests that we throw correct diagnostic exception for a scenario which is not possible with Schannel. So at least on paper there is nothing technical preventig us from switching.

That being said, switching to OpenSSL-MsQuic for public .NET releases may be problematic. It would probably be best to follow the model we use in Linux, where .NET does not ship with msquic.so, but expects it to be installed by a package manager. This way the user can install the appropriate version (OpenSSL vs Schannel) for the Windows version and have potentially quicker access to MsQuic updates than monthly .NET servicing.

[StephenCleary]

I cloned this repo and tried out building my own System.Net.Quic NuGet library, but it wasn't really clear how to do that. If I can make the same modifications and build my own NuGet package, that would be fine; but I'd want to run it on the stock runtime.

I also checked the official net9.0 supported OSes, and Win10 is definitely in the list (as I would expect). If it were just a matter of supporting HTTP/3 when possible and falling back to HTTP/2, this current situation would be fine. But if QUIC itself (i.e., System.Net.Quic) is considered part of the runtime proper, then I'd expect QUIC support on all platforms the runtime supports. Again, IMO.

Now that I've typed all this out, it occurs to me that I could create my own Custom.System.Net.Quic by modifying the NuGet library itself (specifically, its dependencies) rather than attempting a proper fork. Would you say that's a viable path forward? It would assume the msquic API is binary-identical for both backends. And I'm also assuming there wouldn't be an issue with running the Custom.System.Net.Quic on a runtime that might be different than the one it was originally built with.

[rzikm]

But if QUIC itself (i.e., System.Net.Quic) is considered part of the runtime proper, then I'd expect QUIC support on all platforms the runtime supports. Again, IMO.

That would certainly be ideal, but sometimes there are platform gaps which make it difficult to have all features working on all platforms. To give few another example, TLS1.3 is not supported on OSX (#1979), and, neither is System.Net.Quic (because MsQuic does not officially support OSX yet I think).

Now that I've typed all this out, it occurs to me that I could create my own Custom.System.Net.Quic by modifying the NuGet library itself (specifically, its dependencies) rather than attempting a proper fork. Would you say that's a viable path forward? It would assume the msquic API is binary-identical for both backends. And I'm also assuming there wouldn't be an issue with running the Custom.System.Net.Quic on a runtime that might be different than the one it was originally built with.

You can take the source code for System.Net.Quic and compile your own library, but this will not replace the built-in System.Net.Quic.* types, existing libraries (like ASP.NET Core) will still be using the System.Net.Quic.* types they were compiled against.

Maybe, you could just reference the MsQuic-OpenSSL NuGet and have it overwrite the msquic.dll on publish using something like

    <PackageReference Include="Microsoft.Native.Quic.MsQuic.OpenSSL"
                      Version="$(MicrosoftNativeQuicMsQuicOpenSSLVersion)"
                      PrivateAssets="all"
                      GeneratePathProperty="true" />

    <NativeBinPlaceItem Include="$(PkgMicrosoft_Native_Quic_MsQuic_OpenSSL)\build\native\bin\$(TargetArchitecture)\*" />

this will not work during normal development, as we search for the msquic.dll in the same directory as System.Net.Quic.dll (on windows), but this could work for self-contained deployments.

[StephenCleary]

this will not replace the built-in System.Net.Quic.* types, existing libraries (like ASP.NET Core) will still be using the System.Net.Quic.* types they were compiled against.

I'm fine with that.

Perhaps I should have started with my goal. I want to write an app that:

• Uses its own custom protocol over QUIC (nothing to do with HTTP).
• Runs on Windows 10.

Ideally, I'd like to enable this same ability for other apps, too, so it would be even better if I can write a library that:

• Provides the same API as System.Net.Quic.
• Runs on Windows 10.

Hence my current thinking:

1. Figure out how to transform System.Net.Quic.nuget into Something.System.Net.Quic.nuget.
2. Wire this up to monitor the NuGet feed and auto-publish (this part I already know how to do).
3. Write my app using Something.System.Net.Quic.nuget.

[rzikm]

We have discussed this within the team, we could alter the loading code for msquic.dll so that it would first look for msquic.dll next to the entry assembly (and on windows only).

This should allow you to reference Microsoft.Native.Quic.MsQuic.OpenSSL and have the build process place it's binaries to the output directory (using something similar to the xml snippet in my earlier comment).

The change I am proposing would make it work for both development workflows (I tested that dotnet run loads the dll, did not test in Visual Studio) and published apps.

Is this something that would work for you, @StephenCleary? while not OOB, it would only require a couple of lines in the csproj file of the application. This would be for .NET 9.0+ only, I don't see us backporting this to older releases.

[StephenCleary]

I think that would work fine, thanks!