-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Check TargetFramework Using Intrinsic Function #5799
Conversation
Team Triage: We can't do this until both the hosted azure devops build machines and the internal build pool that does our official builds is updated to 16.8. |
PR Title should have |
@Nirmal4G thanks! updated |
Looking at PRs this morning--this should work now. |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Oh, of course: all the Core build job flavors won't work because they build with an old .NET Core SDK. So this is blocked on #5515. |
Is this unblocked now that we're on .NET 5? |
@Forgind Good question. I'll rebase and run the tests again |
4001e78
to
929e40e
Compare
This is ready for review. |
src/Directory.Build.targets
Outdated
@@ -69,6 +69,10 @@ | |||
<PackageReference Update="Microsoft.NETCore.App" PrivateAssets="All" /> | |||
</ItemGroup> | |||
|
|||
<PropertyGroup Condition="'$(MonoBuild)' != 'true' and '$(TargetFrameworkIdentifier)' == ''"> | |||
<TargetFrameworkIdentifier>$([MSBuild]::GetTargetFrameworkIdentifier($(TargetFramework)))</TargetFrameworkIdentifier> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you verify this comes before the one from D.BC.t? Also, is $(TargetFrameworkIdentifier) really not used?
Any recent progress on this? Would be nice to finish it or close it until you're ready to come back to it. |
15d3ba6
to
a6534d0
Compare
a6534d0
to
e0fd7c1
Compare
<TargetFrameworkIdentifier Condition="'$(TargetFrameworkIdentifier)' == ''">$([MSBuild]::GetTargetFrameworkIdentifier($(TargetFramework)))</TargetFrameworkIdentifier> | ||
<TargetFrameworkVersion Condition="'$(TargetFrameworkVersion)' == ''">$([MSBuild]::GetTargetFrameworkVersion($(TargetFramework)))</TargetFrameworkIdentifier> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This worries me. Does it really not conflict with something NuGet does?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a general concern overriding these, so I added the check to see if it didn't already have a value. Do you think this could mess with something nuget does where they do a similar "set it if it isn't already set" check?
When setting these values here, I considered prefixing this with an underscore for safety. Maybe we have a different naming convention for "Values that likely won't change during a build that we store for msbuild specific purposes"?
Co-authored-by: Forgind <Forgind@users.noreply.github.com>
88233b3
to
579949a
Compare
Team triage: This can break projects that don't have TFI defined and don't expect to define it. We fixed this in other ways in other parts of our repo. |
At minimum shouldn't this be <GenAPIShortFrameworkIdentifier Condition="'$([MSBuild]::GetTargetFrameworkIdentifier($(TargetFramework)))' == '.NETFramework'">net</GenAPIShortFrameworkIdentifier>
<GenAPIShortFrameworkIdentifier Condition="'$([MSBuild]::GetTargetFrameworkIdentifier($(TargetFramework)))' == '.NETStandard'">netstandard</GenAPIShortFrameworkIdentifier>
<GenAPIShortFrameworkIdentifier Condition="'$([MSBuild]::GetTargetFrameworkIdentifier($(TargetFramework)))' == '.NETCoreApp'">netstandard</GenAPIShortFrameworkIdentifier> Or save $([MSBuild]::GetTargetFrameworkIdentifier($(TargetFramework))) into some unique property just before this and check that? Or should #5792 be closed? |
Yes, changing the checks to use the property function for our own repo is appropriate. Adding it to common.targets is riskier and I don't think we should do it now. |
@rainersigwald ah too broadly scoped, got it. Will revert it to mostly the first version of this PR |
src/Directory.BeforeCommon.targets
Outdated
@@ -110,7 +110,7 @@ | |||
<DefineConstants Condition="$([MSBuild]::IsOSPlatform('windows'))">$(DefineConstants);TEST_ISWINDOWS</DefineConstants> | |||
</PropertyGroup> | |||
|
|||
<PropertyGroup Condition="'$(MonoBuild)' != 'true' and ($([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'netcoreapp1.0')) or $(TargetFramework.StartsWith('netstandard')))"> | |||
<PropertyGroup Condition="'$(MonoBuild)' != 'true' and $([MSBuild]::GetTargetFrameworkIdentifier('$(TargetFramework)')) == '.NETCoreApp' or $([MSBuild]::GetTargetFrameworkIdentifier('$(TargetFramework)')) == '.NETStandard'"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
src/Directory.BeforeCommon.targets(113,18): error MSB4130: The condition "'$(MonoBuild)' != 'true' and $([MSBuild]::GetTargetFrameworkIdentifier('$(TargetFramework)')) == '.NETCoreApp' or $([MSBuild]::GetTargetFrameworkIdentifier('$(TargetFramework)')) == '.NETStandard'" may have been evaluated incorrectly in an earlier version of MSBuild. Please verify that the order of the AND and OR clauses is written as intended. To avoid this warning, add parentheses to make the evaluation order explicit.
The bug to remove this old warning (#1698) is 4 years old. The warning itself was commited on 2006-06-13 16:04:38
.
😔
However, let's go ahead and overparenthesize.
<PropertyGroup Condition="'$(MonoBuild)' != 'true' and $([MSBuild]::GetTargetFrameworkIdentifier('$(TargetFramework)')) == '.NETCoreApp' or $([MSBuild]::GetTargetFrameworkIdentifier('$(TargetFramework)')) == '.NETStandard'"> | |
<PropertyGroup Condition="'$(MonoBuild)' != 'true' and ($([MSBuild]::GetTargetFrameworkIdentifier('$(TargetFramework)')) == '.NETCoreApp' or $([MSBuild]::GetTargetFrameworkIdentifier('$(TargetFramework)')) == '.NETStandard' )"> |
2c6e350
to
cd4390d
Compare
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Fixes #5792
We had two areas where MSBuild checked TargetFramework based on whether it started with
netcore
andnetstandard
.Ex:
msbuild/src/Directory.BeforeCommon.targets
Line 114 in a710679
With net5.0 resolving to
net5.0
instead ofnetcoreapp5.0
, this logic would no longer succeed, so here's a quick fix via intrinsic functionGetTargetFrameworkIdentifier
introduced in #5429.Some other notes:
There are a few other areas that look like we could use these intrinsic functions, but it would overcomplicate the logic. Here's what I found with
rg -iF "StartsWith('net"
These checks are likely better than