NuGet package(s) for MsQuic generated bindings

[TYoungSL]

Describe the feature you'd like supported

I'd like to see packages consumable by .NET projects on NuGet that expose official MsQuic bindings to the project that are versioned to the signed binaries as they are released.

Currently there are multiple variations across multiple codebases of the generated sources that have different licensing, degrees of compatibility with binding to official native libraries or providing separate native libraries.

As these bindings may be competing or conflicting with the .NET runtime's inclusion of the Microsoft.Quic (internal) bindings as they are wrapped by System.Net.Quic and may not expose the whole of the library, there could be a single consumable source of the generated bindings exposed as a NuGet package that would help avoid conflicts while allowing custom builds and bindings and add support and ownership of the bindings (and any compatibility, faciliatory code) to official sources.

Proposed solution

One or more official .NET NuGet packages.

• [ ] 1) Provide the generated bindings source to the project maintaining internal access specifiers.
  • [ ] b) Multiple consumers should not conflict.
• [ ] 2) Provide native library resolution.
  • [ ] a) Multiple consumers should not cause conflicts.
• [ ] 3) Provide compatibility with most recent .NET versions.
  • [x] a) Not .NET framework.
  • [x] b) Provide support down to .NET Standard 2.0 for use with e.g. Unity's Mono or other (mobile) platforms.
    • Requires some polyfills, maybe sans usage of NativeLibrary.
• [ ] 4) Provide native runtime packages.
  • [ ] a) As separate packages.
  • [ ] b) Bundled with the source.

Additional context

From the Thursday meeting, per @ThadHouse, we discussed (some of) the changes required to support it.

[O-Keh-Hunter]

Is there any progress?