Should EnableFrameworkPathOverride be set for net50 TFM

[JunTaoLuo]

Hey folks, while I'm ingesting the new SDK and updating our TFM to net5.0, I ran into the following error:

.dotnet/sdk/5.0.100-preview.5.20258.4/Microsoft.Common.CurrentVersion.targets(84,5): error MSB4184: (NETCORE_ENGINEERING_TELEMETRY=Restore) The expression "[Microsoft.Build.Utilities.ToolLocationHelper]::GetPathToStandardLibraries(_, v.0, '', '', '', '')" cannot be evaluated. Input string was not in a correct format.

Tracking this part down a little it seems like the property EnableFrameworkPathOverride used to be set to false for apps targeting netcoreapp5.0 but now due to the change in tfm, the logic there is skipped and therefore the the line in Microsoft.Common.CurrentVersion.targets fails:

<FrameworkPathOverride Condition="'$(EnableFrameworkPathOverride)' != 'false' And '$(FrameworkPathOverride)' == ''">$([Microsoft.Build.Utilities.ToolLocationHelper]::GetPathToStandardLibraries($(TargetFrameworkIdentifier), $(TargetFrameworkVersion), $(TargetFrameworkProfile), $(PlatformTarget), $(TargetFrameworkRootPath), $(TargetFrameworkFallbackSearchPaths)))</FrameworkPathOverride>

What is the expected behaviour and what should we be doing to resolve this? Who would be the best person to answer this question? @dsplaisted @wli3 @peterhuene

[JunTaoLuo]

FYI @wtgodbe @dougbu @Pilchie since this seems to be blocking our runtime ingestion at dotnet/razor#1873. I'm currently trying to work around the problem but it would be nice to understand what the proper fix is.

[dsplaisted]

The TargetFrameworkIdentifier for net5.0 is still .NETCoreApp, so _IsNETCoreOrNETStandard should still be true and EnableFrameworkPathOverride should be false.

I'm not sure why that wouldn't be the case. Perhaps there is something else setting some of these properties, or maybe part of the SDK is outdated.

[dougbu]

@JunTaoLuo worked around the problem but why is https://github.com/dotnet/aspnetcore-tooling/pull/1873/files#diff-4b2f402501d23abbede6eac0f47783e4R38 necessary? I don't see significant differences in the order $(TargetFrameworkIdentifier), $(_IsNETCoreOrNETStandard), or $(EnableFrameworkPathOverride) are evaluated.

Will temporarily undo the workaround to make sure it's still needed…

[dougbu]

My temporary undo of that change and one other failed miserably: https://dev.azure.com/dnceng/public/_build/results?buildId=638882 Trying again w/ just one undo.

[JunTaoLuo]

FYI, we've worked through the issues and it turns out to mostly have been caused by our misunderstanding.

[dougbu]

… and desktop msbuild using different files than dotnet msbuild.