Supporting Nano Server and Windows Desktop #8894
Description
Details about Problem
When creating native libraries, there is no way to get NuGet to install a different set of native runtime assets when running on Nano Server vs Windows Desktop or Server Core.
Typically, I would place my Win32 assets in the runtimes/win-x64/native directory and this works in most cases. However, Nano Server is both Win32 and not Win32. It is in the case that most binaries will work in both cases, but not in the case where I use some features not available on Nano Server. For example font subsetting using the FONTSUB.DLL.
It has been suggested in other issues that I should do some runtime detection for Nano Server and then not do something. This could work, but will require a fair bit of effort - especially since the native library is a third party library.
Having a look around, I see a similar situation with Win32 and UWP assets. Technically, UWP is Windows, yet they have their own RID. In fact, UWP is the perfect example, as it is a win10, but has nativeassets of uap10.0: runtimes/win10-x64/nativeassets/uap10.0/libSkiaSharp.dll.
The case of UWP being a a TFM under win seems to make sense, but actually is is a bit wrong. The spec for the nativeassets specifies that pretty much any TFM can go there. If wee look at /runtimes/{rid}/nativeassets/{txm}/ we can see that we could potentially add an iOS or Android native binary there. What is the point of having /runtimes/win10-x64/nativeassets/xamarin.ios/libSkiaSharp? That makes no actual sense. Even the concept of having uap under win10 is a bit weird. Why not have /runtimes/uap10.0/? Isn't that the who point of the runtimes folder? To select the correct native binaries for the runtime, based on the runtime? It looks to me if I have a native binary that works on both win10 and nano, then it should be fine to have it in /runtimes/win10-x64/ and it will use the same in both places. But if not, then I should be splitting it up under the nativeassets.
The original issue for this feature was to distinguish UWP from Win10, but in actual fact, they were wanting to distinguish between a feature-set or subset of features of a platform. So the base is win10, and then we have UWP or Nano.
I opened this issue previously: #7375