Supporting Nano Server and Windows Desktop

[nkolev92]

@mattleibow commented on Mon, 09 Dec 2019 22:59:54 GMT

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: NuGet/Home#7375

[nkolev92]

@donnie-msft commented on Sat, 14 Dec 2019 18:33:17 GMT
//cc @rrelyea @nkolev92

[nkolev92]

@nkolev92 commented on Mon, 16 Dec 2019 20:02:35 GMT
//cc @nguerrera @eerhardt @dsplaisted @livarcocc thoughts?

[mattleibow]

The perfect opportunity to change anything will be with the upcoming .NET 5.

[joperezr]

I'm not sure what is the expectation for this issue from the dotnet/runtime repo side, I believe that in order to support something like this most of the work would be into creating a new NuGet convention which would then specify either a new TFM or something to differentiate Nano Server.

[nkolev92]

@joperezr

NuGet owns the tfm mapping, but the compatibility decisions are made by runtime and net in general.

cc @terrajobst would have the most context here.

[dsplaisted]

@joperezr Wouldn't this be handled with a different RuntimeIdentifier?

[ericstj]

We don't intend to represent different Windows SKUs in the RID graph. If you have different binaries in these cases your library should handle those cases through dynamic loading. If you need it to be handled at build time that can be done with targets in the nuget package.

[ericstj]

cc @eerhardt @richlander