Sdk: Set default TargetPlatformVersion for Windows

Created on 10 Apr 2020  路  12Comments  路  Source: dotnet/sdk

If the TargetFramework specifies windows as the TargetPlatformIdentifier but doesn't set the TargetPlatformVersion, then the SDK should set the version. This should go in the WindowsDesktop targets, and in the WindowsDesktop optional workload if/when it becomes an optional workload.

IE, the TargetFramework might be net5.0-windows. We haven't closed on what the default TargetPlatformVersion would be, but it might be 7, or some version of Windows 10 (10.0.18362).

Note that once this default is set for a given TargetFrameworkVersion, it can't be changed for that TargetFrameworkVersion, but for newer TargetFrameworkVersions it could be updated.

EDIT: For .NET 5.0 the default version of Windows should not be a version that includes WinRT APIs. This is because the CSWinRT shims for those APIs will add to the app size, and many WPF / Windows Forms apps won't use CSWinRT (but will have a TargetFramework of net5.0-windows).

EDIT: We also should normalize the casing of Windows for the TargetPlatformIdentifier. This is because it will be lower case when we parse a TargetFramework such as net5.0-windows. We may as well track normalizing the case with this issue. It's probably just the following code:

<!-- Normalize casing of windows to Windows -->
<TargetPlatformIdentifier Condition="'$(TargetPlatformIdentifier)' == 'Windows'">Windows</TargetPlatformIdentifier>

Most helpful comment

We discovered recently that all projects that don't specify a TargetPlatformVersion already have it set to 7.0 (whether they are intended to target Windows or not). See https://github.com/microsoft/msbuild/pull/5391 and https://github.com/dotnet/sdk/pull/12084.

So I think we can be confident there aren't currently any other implications of this value.

Once we ship .NET 5, we will be stuck with the default target platform version for net5.0-windows, but we would be able to change the default platform version for future versions of .NET, e.g. net6.0-windows. So if we do start using this value to generate application manifests, we should consider changing the default TargetPlatformVersion for the .NET release that goes along with.

All 12 comments

FYI @vatsan-madhavan @wli3

also /cc @dotnet/wpf-developers, @dotnet/dotnet-winforms

We decided 7.0 is the default

We decided 7.0 is the default

Rationale?

@vatsan-madhavan this is a conclusion from a meeting. But I cannot find the note. @dsplaisted is OOF this week. He can give you that when he is back.

See the (new) last paragraph in the issue description:

EDIT: For .NET 5.0 the default version of Windows should not be a version that includes WinRT APIs. This is because the CSWinRT shims for those APIs will add to the app size, and many WPF / Windows Forms apps won't use CSWinRT (but will have a TargetFramework of net5.0-windows).

Are there other implications of this value? I鈥檓 esp concerned that this value could be used in the future to generate application-manifests with OS compatibility levels in them. Or is this strictly about CsWinRT only?

Neither WPF nor WinForms is optimized any longer for Win7, and we shouldn鈥檛 inadvertently design ourselves into a default that triggers OS fallback behaviors in each of these stacks that is meant for Win7/Vista compat.

/cc @merriemcgaw

We discovered recently that all projects that don't specify a TargetPlatformVersion already have it set to 7.0 (whether they are intended to target Windows or not). See https://github.com/microsoft/msbuild/pull/5391 and https://github.com/dotnet/sdk/pull/12084.

So I think we can be confident there aren't currently any other implications of this value.

Once we ship .NET 5, we will be stuck with the default target platform version for net5.0-windows, but we would be able to change the default platform version for future versions of .NET, e.g. net6.0-windows. So if we do start using this value to generate application manifests, we should consider changing the default TargetPlatformVersion for the .NET release that goes along with.

@sfoslund @wli3 note my addition to the issue description:

We also should normalize the casing of Windows for the TargetPlatformIdentifier. This is because it will be lower case when we parse a TargetFramework such as net5.0-windows. We may as well track normalizing the case with this issue. It's probably just the following code:

<!-- Normalize casing of windows to Windows -->
<TargetPlatformIdentifier Condition="'$(TargetPlatformIdentifier)' == 'Windows'">Windows</TargetPlatformIdentifier>

The windows default TargetPlatformVersion was set by dotnet/wpf#3177. Leaving this open to track normalizing the casing of Windows for the TargetPlatformIdentifier, which will be fixed in #12202

This is done but it's duplicated between WPF and SDK (in PR) and we should remove it from WPF. @wli3

Was this page helpful?
0 / 5 - 0 ratings