Set default TargetPlatformVersion for Windows

[dsplaisted]

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>

[dsplaisted]

FYI @vatsan-madhavan @wli3

[vatsan-madhavan]

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

[dsplaisted]

• Reference for format for TargetPlatformVersion and TargetPlatformMinVersion
• Versions of Windows for UWP

[wli3]

We decided 7.0 is the default

[vatsan-madhavan]

We decided 7.0 is the default

Rationale?

[wli3]

@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.

[dsplaisted]

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).

[vatsan-madhavan]

Are there other implications of this value? I’m 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’t 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

[dsplaisted]

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 dotnet/msbuild#5391 and #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.