Source distribution of native libraries via NuGet

[jkotas]

It is not unusual for NuGet packages to contain native libraries. Today, the NuGet package author is responsible for providing native libraries for all platforms that the NuGet package can run on. If the consumer of the library wishes to use the library on a platform that is not on this list, there is no simple standard way for how to recompile the native library for the new platform. Most users just give up.

Other ecosystems solve this problem by having both source and binary distributions of native libraries. For example, the Python ecosystem has wheels (binary distribution) and sdist (source distribution) that is used as fallback when the appropriate binary distribution is not available. More details in https://packaging.python.org/tutorials/installing-packages/#source-distributions-vs-wheels.

This issue is start of the discussion to add source distribution option for native libraries via NuGet packages.

Related: #5862, dotnet/runtime#37213

cc @AaronRobinsonMSFT

[AaronRobinsonMSFT]

This seems like an opportunity for NuGet to work with https://github.com/microsoft/vcpkg and provide a unified solution. I could imagine NuGet having an internal reference to or fully embedded vcpkg. I think it would be unfortunate if NuGet needed to reinvent native build support.

/cc @ras0219-msft

[rrelyea]

Source files can be distributed for packages via .symbols.nupkg files (gen1 of nuget symbols format). Or via sourcelink in the .pdb inside a .snupkg (gen2 of nuget symbols format).

That said, agree with @AaronRobinsonMSFT that we should have the conversation including the vcpkg team. @ras0219-msft
@anangaur

[nkolev92]

Triage: @anangaur can you please follow up to understand the requirements for this ask.

@jkotas @AaronRobinsonMSFT If this is a high enough priority, please reach out to @anangaur and @aortiz-msft

[aortiz-msft]

@JonDouglas - Would you please follow up with @jkotas on the above designs?