Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set default TargetPlatformVersion for Windows #11233

Closed
dsplaisted opened this issue Apr 10, 2020 · 12 comments · Fixed by dotnet/wpf#3177
Closed

Set default TargetPlatformVersion for Windows #11233

dsplaisted opened this issue Apr 10, 2020 · 12 comments · Fixed by dotnet/wpf#3177
Assignees
Milestone

Comments

@dsplaisted
Copy link
Member

dsplaisted commented Apr 10, 2020

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 dsplaisted added this to the 5.0.1xx milestone Apr 10, 2020
@dsplaisted
Copy link
Member Author

FYI @vatsan-madhavan @wli3

@vatsan-madhavan
Copy link
Member

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

@dsplaisted
Copy link
Member Author

@wli3
Copy link

wli3 commented Jun 25, 2020

We decided 7.0 is the default

@vatsan-madhavan
Copy link
Member

We decided 7.0 is the default

Rationale?

@wli3
Copy link

wli3 commented Jun 25, 2020

@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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member Author

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.

@dsplaisted
Copy link
Member Author

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

@sfoslund
Copy link
Member

sfoslund commented Jul 2, 2020

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

@marcpopMSFT
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants