Supported OS?

[Rand-Random]

I would like to ask if the page
https://github.com/dotnet/core/blob/master/release-notes/5.0/5.0-supported-os.md

should also list the supported Operating Systems for the OS specific target frameworks?
https://docs.microsoft.com/en-us/dotnet/standard/frameworks#net-5-os-specific-tfms

Or is it always guaranteed that eg. "net5.0-windows" will run on all Windows plattforms that "net5.0" support, is there no additional limitation?

[mairaw]

@rbhanda @leecow can you look at this?

[terrajobst]

@Rand-Random I'm not sure I understand. Is the concern merely around the version number? net5.0-windows is special in that it's the only TFM really where we allow developers to omit the version from the project file. For the others we'll generally push developers to specify the version number.

net5.0-windows is just a shorthand for net5.0-windows7.0.

[Rand-Random]

@terrajobst
On this page you can see all the supported Operating Systems which net.5.0 supports (without any suffix).
https://github.com/dotnet/core/blob/master/release-notes/5.0/5.0-supported-os.md

My question is if the suffix further limits the supported Operating Systems or not.
eg. does "net5.0-windows" support the "Nano Server", or is there a possibility that the "windows" suffix limits the support.

[danmoseley]

The Windows suffix does not exclude any versions of Windows that are among the supported list of Windows versions that we document. A few API do not work on Nano Server and will throw at runtime.

[Rand-Random]

@danmoseley
Isn’t that contradicting, to say there isn’t an exclusion but in the next statement to say that some APIs exclude support for Nano Server.

Also I mentioned Nano Server and Windows just as an example what about all the other flavors? And you didn’t comment about my initial question were I asked if the Page https://github.com/dotnet/core/blob/master/release-notes/5.0/5.0-supported-os.md should include the limitation.

Did have a look and didn’t see an edit that some APIs are excluded for certain Operating Systems.

[terrajobst]

I think I understand the concern now.

The target framework name (TFM) is a .NET concept. It represents the set of .NET APIs provided by the .NET platform itself. It allows us to have different flavors of .NET where the API set differs. In the past this was a bit of a wild west situation. With .NET Standard we have formalized a common subset of APIs which we have then further formalized into the new TFM syntax of .NET 5.

The intent is that net5.0 (and subsequent versions) represent that cross-platform API set while net5.0-xxxxA.B represent the operating system specific (.NET) APIs for OS XXXX A.B. There is some confusion what the operating system specific API set means here. The .NET platform can run on many different operating systems (several SKUs of Windows, several different Linux distros, macOS, several different flavors of iOS, and of course Android). Not all of them have a corresponding TFM. Why is that? Well, TFMs are fairly heavy beasts. We only add them for cases where we have .NET APIs that are specific to this platform. In .NET 5 that was only the case for Windows; with .NET 6 we're expanding this to macOS, various iOS flavors, and Android.

We can, in principle, extend the list of TFMs indefinitely. However, it only makes sense for cases where there is a set of .NET APIs that are only available to a particular operating system. We call those bindings; bindings are different from P/invokes because bindings are sometimes wrappers, sometimes hand authored, and sometimes auto generated. They tend to be large which is why we generally don't want to make them available for other platforms by having them throw. Examples for bindings include WPF, WinForms, WinRT APIs such as WinUI, and the Xamarin APIs for iOS & Android. Please note that those are different from the underlying native APIs (such as Win32) -- TFMs don't model those; TFMs model .NET APIs only.

Generally speaking, if you want to P/Invoke to Windows and Linux depending where you you run you don't have to target different TFMs. Instead, in your implementation you declare all the P/Invokes across all the operating systems you care about, do a platform check, and then call the appropriate P/Invoke. But if you really want you can also build a NuGet package that provides different binaries, even if there is no TFM. You can do this via runtime identifiers (RIDs). RIDs allow you to provide different implementations based on architecture (e.g. x64 vs x86), OS (e.g. win vs redhat), and even OS version. There are many more RIDs than there are TFMs. However, in order to contain the exploding complexity, there is a huge difference between TFMs and RIDs: a NuGet package cannot vary API surface based on RID. Another way to think about this is: a TFM is used to select which assembly to pass to the compiler whereas a RID controls which assembly gets deployed with the application. Furthermore, a NuGet package cannot differ its dependencies by RID, only by TFM (same rationale). This means while the RIDs can be complex, a given NuGet dependency graph and which assemblies you're compiling against is only governed by the TFM. RIDs only come to play when NuGet determines which files to copy to the application output.

So to summarize: .NET supports many platforms which you can find the RID list. We only define TFMs for platform for which .NET is providing a large API surface that doesn't make sense to other platforms.

[danmoseley]

@Rand-Random does this answer your question? we can reactivate if not.

[Rand-Random]

@terrajobst
Thanks for explanation.

@danmoseley
I believe to have understand the difference, though it is more complicated than I thought it would be.

IMHO, I believe it would be better to mention in https://github.com/dotnet/core/blob/master/release-notes/5.0/5.0-supported-os.md that this list doesn't mean it is 100% supported but any Operating System could throw on any number of APIs a runtime exception.

Maybe it is just me, but when I read this and that operating system is supported I tend to believe everything (100%) will run just fine on those operating systems and not that some APIs are unsupported on runtime level.

I am not implying there should be complete list of which API a operating system supports and which it does not, cause when I had a look the provided RID list I believe it could be sheer endless list of APIs and their supported OS.

But just maybe a little remark that some APIs are unsupported, and how a developer can verify if the app that was written does support this and that.

[danmoseley]

@Rand-Random have you tried this? https://docs.microsoft.com/en-us/dotnet/standard/analyzers/platform-compat-analyzer
It's intended to flag API's like this.