System.Private.CoreLib's "Platform" is always set to AnyCPU when building inside Visual Studio which causes build failures

[ViktorHofer]

Reported in #97969

When building System.Private.CoreLib as a dependency of i.e. System.Threading.csproj, the Platform global property is always set to AnyCPU even though dotnet/runtime sets it to TargetArchitecture:

runtime/src/coreclr/Directory.Build.props

Line 3 in cb0e160

<InferPlatformFromTargetArchitecture>true</InferPlatformFromTargetArchitecture>

Looking at a full fidelity binlog created by the project system tools, I can see that this is related to our custom Microsoft.DotNet.Build.Tasks.TargetFramework component:

The target from our custom component is slightly different than what is inbox in msbuild: https://github.com/dotnet/msbuild/blob/bea6b4aebe6548d714ca643db9107162965b94d5/src/Tasks/Microsoft.Common.CurrentVersion.targets#L1755-L1951

Probably most relevant is that our custom target doesn't support the EnableDynamicPlatformResolution setting which might be the reason why SetPlatform is passed in with a value of "AnyCPU".

This causes builds to fail, i.e. .\build.cmd -os browser -subset mono+libs && .\build.cmd -vs src\libraries\System.Runtime.InteropServices.JavaScript\System.Runtime.InteropServices.JavaScript.sln -rf Mono -os browser:

cc @ericstj

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Reported in #97969

When building System.Private.CoreLib as a dependency of i.e. System.Threading.csproj, the Platform global property is always set to AnyCPU even though dotnet/runtime sets it to TargetArchitecture:

runtime/src/coreclr/Directory.Build.props

Line 3 in cb0e160

<InferPlatformFromTargetArchitecture>true</InferPlatformFromTargetArchitecture>

Looking at a full fidelity binlog created by the project system tools, I can see that this is related to our custom Microsoft.DotNet.Build.Tasks.TargetFramework component:

The target from our custom component is slightly different than what is inbox in msbuild: https://github.com/dotnet/msbuild/blob/bea6b4aebe6548d714ca643db9107162965b94d5/src/Tasks/Microsoft.Common.CurrentVersion.targets#L1755-L1951

Probably most relevant is that our custom target doesn't support the EnableDynamicPlatformResolution setting which might be the reason why SetPlatform is passed in with a value of "AnyCPU".

This causes builds to fail, i.e.:

cc @ericstj

Author:	ViktorHofer
Assignees:	-
Labels:	area-Infrastructure
Milestone:	-

[ericstj]

Seems like you're on to something. IIRC the way the TargetFramework selection works is we run a target early to calculate the TargetFramework properties ourselves, then we set SkipGetTargetFrameworkProperties on those projects to apply the TFM.

I noticed this:
https://github.com/dotnet/msbuild/blob/bea6b4aebe6548d714ca643db9107162965b94d5/src/Tasks/Microsoft.Common.CurrentVersion.targets#L1834-L1860

The second call when '$(EnableDynamicPlatformResolution)' == 'true'" removes additional properties Platform;Configuration;

@ViktorHofer - maybe give a try of modifying https://github.com/dotnet/arcade/blob/8cfc9489d3e51071fedec9dcb99071dc912718bd/src/Microsoft.DotNet.Build.Tasks.TargetFramework/src/build/Microsoft.DotNet.Build.Tasks.TargetFramework.targets#L43-L54 to do this and see if it fixes the issue?

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[ViktorHofer]

We don't opt into using EnableDynamicPlatformResolution in runtime. That second call in the Common.targets from the link above can be ignored.