When building a .NET Core self-contained deployment, are higher target OS versions better?

2
votes

When creating a self-contained .NET Core deployment, you're required to specify a Runtime ID of your target platform, such as win7-x64 or win10-x64.

We've found that these targets are backwards-compatible (I can run an application targeting win7-x64 on my Windows 10 developer machine).

My question is: is there any benefit to targeting the highest possible Runtime ID? Our servers are 2008 R2, meaning we have to target win81-x64 or lower. Are there runtime considerations of targeting win81-x64 vs win7-x64?

1
.net.net-coreproject.json
You should only target a higher version if you have a reason. Either some dependencies rely on that, or you just want to stop supporting an older OS. – Lex Li
I suspect this distinction exists to isolate WinRT apps (aka UWP, aka Phone, aka Store, aka Modern UI). Which isn't supported by Win7. So if you don't target WinRT then relying on win7-x64 give you the maximum number of OS versions you can support. – Hans Passant

1 Answers

3
votes

Here is a good document explains Runtime IDs, and how they relate to each other.

RIDs (Runtime IDs) have a fallback mechanism that is laid out in the runtime.json file in that folder.

There are some cases where you can get a better asset using a higher RID, for example if a NuGet package had win7 assets and win10 assets, where the win10 assets lit up functionality that comes in win10. These cases don't happen often and don't really happen in the core .NET runtime, but it is possible in 3rd party packages.

My suggestion would be to use the RID for the lowest OS version you are targeting. If you don't intend to ever support win7 in your app, then use win8 or higher.