[QUIC] CI doesn't run the tests

[ManickaP]

ATM, we depend on Insider Preview version of Windows, see https://github.com/dotnet/runtimelab/tree/feature/System.Net.Experimental.MsQuic#usage.
For that reason, we are not running any QUIC tests in CI pipelines.

Figure out how to enable them. Figure out how to enable them for Linux and MacOS as well (probably depends on open questions around OpenSSL).

cc: @CarnaViire @wfurt @scalablecory

[ghost]

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

Issue Details

---

ATM, we depend on Insider Preview version of Windows, see https://github.com/dotnet/runtimelab/tree/feature/System.Net.Experimental.MsQuic#usage.
For that reason, we are not running any QUIC tests in CI pipelines.

Figure out how to enable them. Figure out how to enable them for Linux and MacOS as well (probably depends on open questions around OpenSSL).

cc: @CarnaViire @wfurt @scalablecory

Author:	ManickaP
Assignees:	-
Labels:	area-System.Net.Quic, test enhancement
Milestone:	6.0.0

[scalablecory]

Triage: @ViktorHofer @safern we think this might be solvable if we have our csproj test files download a msquic lib on Linux -- does this seem reasonable? Can you help us with the changes?

This would only be temporary until we figure out how we want to package msquic.

[scalablecory]

Before we enable in CI, we should fix tests to run locally.

[safern]

if we have our csproj test files download a msquic lib on Linux

Would this be the same for al distros? Where are you going to download the lib into? Do we want to it be dynamic (downloaded before every run if needed) or should we have that as a machine requirement?

[wfurt]

we will need separate binaries for musl based distros like Alpine. Rest should work fine. msquic project has CI but I don't know if they produce consumable binaries.

[Tratcher]

FYI we got the Helix Windows.10.Amd64.ClientPre.VS2019.Pre queue set up with windows insiders builds. It's currently updating ~monthly. This queue can only be used on internal azdo builds so we have a nightly job that runs it.

Is there a specific minimum windows build version required?

[ViktorHofer]

This would only be temporary until we figure out how we want to package msquic.

Before attempting any intermediate steps, why not figure out how to package msquic first? If the msquic repo provides a nuget package, the lib can be consumed easily.

[wfurt]

It does not but it possibly can even if that is just transient package. On Windows, all needed bits will be part of .NET runtime. The alternative is to pull in msquic code and make that part of runtime build. I think that is what @safern help us to do for the runtime lab experiment.

[ViktorHofer]

Would that create a source dependency just for testing or also for the product? Preferably we would not build the msquic repo as part of our build.

[wfurt]

We will need to solve it somehow for the product as well. cc: @dleeapho @NikolaMilosavljevic @nibanks
basically on Windows msquic will be part .NET runtime.
On Linux we will build native bits and publish them on packages.microsoft.com. (because of crypto complications)

I'm not sure of this is best way how to track the product changes but it seems related and we have all the right minds here now.

I personally feel the same way @ViktorHofer but we will need to find a way how to bundle it to the product.

[ViktorHofer]

I'm not sure of this is best way how to track the product changes but it seems related and we have all the right minds here now.

Agreed. Let's have the product related discussion here as well. Distributing msquic as part of the runtime pack is actually quite easy. We could either bring it along as a dependency of one of the runtime libs (which assembly exactly has a dependency on it?) or directly reference it in the runtime pack shared framework package. Either way, we need a nuget package or multiple nuget packages (RID based) to consume msquic in dotnet/runtime.

[nibanks]

So, is the ask (or at least line of thought) that MsQuic produce a NuGet package that .NET would consume on Windows. (FYI @ThadHouse)

[ManickaP]

We run the tests on a docker image for Linux, for Windows we have an opened issue with infra to provide us with new enough Win images. The rest of the packaging tasks is tracked here #55639. Closing in favor of that.