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

Fixes problems in WindowsDesktop SDK due to _TargetFrameworkVersionWithoutV being undefined sometimes #1713

Merged
9 commits merged into from
Aug 27, 2019

Conversation

vatsan-madhavan
Copy link
Member

@vatsan-madhavan vatsan-madhavan commented Aug 24, 2019

[release/3.0 version of #1707]

Fixes #1651 - Invalid comparison in MSBuild's ignore-conditions mode in outer build of multitargeted project

This change ensures that the WindowsDesktop SDK never deals with undefined numeric values related to TFM.

This solution leverages the fact that Items are evaluated after Properties by MSBuild. See Comparing properties and items

_TargetFrameworkVersionValue - a new Property which is defined for exclusive use within the WindowsDesktop SDK, and which is intended to act as a proxy for _TargetFrameworkVersionWithoutV - is defined in Microsoft.NET.Sdk.WindowsDesktop.targets after TargetFrameworkVersionWithoutV is guaranteed to be defined by Microsoft.NET.Sdk.targets.

Even here, we ensure that a fallback default (0.0) is provided - guaranteeing that _TargetFrameworkVersionValue will always be numeric.

When the Conditions in the various Items in Microsoft.NET.WindowsDesktop.props are evaluated (which will happen strictly after all Properties are evaluated - whether they appear in .props or .targets), _TargetFrameworkVersionValue would have been (a) well-defined and (b) guaranteed to be a numeric value. This would in turn guarantee that errors of the kind "A numeric comparison was attempted on "$(_TargetFrameworkVersionValue)" that evaluates to "" instead of a number," will no longer appear in outer-builds or in any other context.

PS: This is a fix for a regression introduced by #1027 (which shipped in Preview 6) as part of a set of fixes for improving multi-targeting experience, improved warnings and error messages during build, and improvements to project-system integration.

@ghost ghost requested review from rladuca, ryalanms and stevenbrix August 24, 2019 00:21
@ghost ghost added the PR metadata: Label to tag PRs, to facilitate with triage label Aug 24, 2019
@ghost ghost requested a review from SamBent August 24, 2019 00:21
@vatsan-madhavan vatsan-madhavan added this to the 3.0 milestone Aug 24, 2019
@vatsan-madhavan vatsan-madhavan added the * NO MERGE * metadata: The PR is not ready for merge yet (see discussion for detailed reasons) label Aug 24, 2019
@vatsan-madhavan
Copy link
Member Author

Marking as *NO MERGE* until we receive permission to merge this change into release/3.0 branch.

@vatsan-madhavan vatsan-madhavan added auto_merge bot-command and removed * NO MERGE * metadata: The PR is not ready for merge yet (see discussion for detailed reasons) labels Aug 26, 2019
@ghost
Copy link

ghost commented Aug 26, 2019

Hello @vatsan-madhavan!

Because this pull request has the auto_merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 3b48663 into release/3.0 Aug 27, 2019
@ghost ghost deleted the dev/vatsan/tfmwithoutvforwpf-rel30 branch August 27, 2019 07:20
@mrward
Copy link

mrward commented Aug 30, 2019

@vatsan-madhavan - Do we know which .NET Core 3.0 sdk version will contain this change?

@vatsan-madhavan
Copy link
Member Author

This was merged 4 days ago - I would think that it would be already in the latest builds in https://github.com/dotnet/core-sdk. Have you had a chance to try out the latest build from there yet?

@mrward
Copy link

mrward commented Aug 31, 2019

I have tried 3.0.100-preview9-014004 which looks to be more recent than what is on core-sdk and that does not seem to include the fix yet. Will try one of the core-sdk builds.

@mrward
Copy link

mrward commented Aug 31, 2019

dotnet/core-sdk seem to have more recent versions of the .NET Core sdk: 3.0.100-rc1-014162

Using https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/3.0.1xx/dotnet-sdk-latest-osx-x64.pkg the fix does not yet seem to be included.

/usr/local/share/dotnet/sdk/3.0.100-rc1-014162/Sdks/Microsoft.NET.Sdk.WindowsDesktop/targets/Microsoft.NET.Sdk.WindowsDesktop.props(112,53) : error MSB4086: A numeric comparison was attempted on "$(_TargetFrameworkVersionWithoutV)" that evaluates to "" instead of a number, in condition "'$(_TargetFrameworkVersionWithoutV)' >= '4.0'".

Presumably it will land in a later release.

@mrward
Copy link

mrward commented Sep 10, 2019

Tried out 3.0.100-rc2-014198 from dotnet/core-sdk and that includes these changes. Thanks.

@ghost ghost locked as resolved and limited conversation to collaborators Apr 15, 2022
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
ask-mode auto_merge bot-command PR metadata: Label to tag PRs, to facilitate with triage
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants