Differentiating Between Win10 and Nano Server

[mattleibow]

I am not too sure if this is the correct place, but this is not really a problem - more a question.

I am building a library (SkiaSharp) that does some font subsetting using the FONTSUB.DLL. This may be an old feature that I shouldn't use, but right now I am (I will investigate this further).

As a result, SkiaSharp cannot be used on Nano Server due to this dll being unavailable. I can compile another binary that does not have this feature, but I still have to support the full set.

My question is this, if I have 2 binaries - one for Nano Server and one for Windows Server, but I can't see a way to distinguish between the two platforms. Right now I am using the runtimes folder in the NuGet - currently the win7-x64 sub-dir. Is there a nanoserver variant?

The original discussion is here with missing assemblies and entry points: mono/SkiaSharp#591 (comment)

[rrelyea]

It sounds like you need to have runtime behavior be different for these two different environments.
I think you code needs to detect this case, and act differently.

Different runtimes won't solve this for you, even if NuGet did know the difference between different SKUs of the same version of windows. (As you'd want one set of binaries to be installed by your app/component)

[nkolev92]

Closing per @rrelyea's comment.

[mattleibow]

So are you suggesting that I write some extra logic in the part that loads the native binaries to make sure I select the correct binary? This is a lot of extra work to get around the fact that Nano is a different windows. Technically, UWP is windows, yet they have their own RID. Now, sure, UWP is a different model, but if I had that feature, then I don't have to worry about loads of code selecting a dll based on the runtime. Literally, the R in RID is Runtime, so the dotnet run or dotnet publish should support this.

UWP is the perfect example actually, it is a win10, but has nativeassets of uap: runtimes/win10-x64/nativeassets/uap10.0/libSkiaSharp.dll

This was suggested on my other issue (#5042) and this feature was added to solve this very problem (#2782)

Can we not add nano? runtimes/win10-x64/nativeassets/nano/libSkiaSharp.dll

EDIT

Well actually, the nano is not a TFM so technically it is wrong. But maybe the spec for the case of /runtimes/{rid}/nativeassets/{txm}/ really is wrong. 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.

I think that my issue actually points out the real problem here. 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.

This will bring in a feature support for macOS and the new Catalyst feature - running iOS apps on macOS. @migueldeicaza How are we doing this right now? Depending on the base of this feature, we may want to do something in the lines of:

• /runtimes/xamarin.ios/native.framework
• /runtimes/xamarin.ios/nativeassets/catalyst/native.framework
• /runtimes/xamarin.mac/nativeassets/ios/native.framework

What this issue is really trying to do is distinguish between different variants of Win10. This might be further extended (as in the Catalyst example) to other operating systems that have variants with 90% features, but require distinct features.

[mattleibow]

@rrelyea @nkolev92 Just pinging you so this issue isn't missed.