[Bug]: `dotnet workload restore` uniquely emits warning MSB3982: EnableDynamicPlatformResolution ... Platforms not set

[AArnott]

Issue Description

Platform negotiation seems to fail with MSB3982, but only for dotnet workload restore commands. Ordinary dotnet restore and dotnet build produce no such warnings.

Steps to Reproduce

git clone https://github.com/AArnott/Library.Template
cd Library.Template
git checkout bug/traversalPlatforms
cd azure-pipelines
dotnet build # no warnings
dotnet workload restore # senseless warnings

Expected Behavior

No warnings or errors.

Actual Behavior

Warnings are emitted about needing Platforms or Platform defined, though they don't make sense, and don't appear for ordinary builds.

C:\Program Files\dotnet\sdk\8.0.303\Microsoft.Common.CurrentVersion.targets(1716,5): warning MSB3982: EnableDynamicPlatformResolution is true but referenced project 'C:\Users\andarno\source\repos\Library.Template\src\dirs.proj' has no 'Platforms' or 'Platform' metadata set. It will be built without a specified platform. C:\Program Files\dotnet\sdk\8.0.303\Microsoft.Common.CurrentVersion.targets(1716,5): warning MSB3982: EnableDynamicPlatformResolution is true but referenced project 'Library\Library.csproj' has no 'Platforms' or 'Platform' metadata set. It will be built without a specified platform.

Analysis

No response

Versions & Configurations

dotnet --info

.NET SDK: Version: 8.0.303 Commit: 29ab8e3268 Workload version: 8.0.300-manifests.d7126b9e MSBuild version: 17.10.4+10fbfbf2e

Runtime Environment: OS Name: Windows OS Version: 10.0.22631 OS Platform: Windows RID: win-x64 Base Path: C:\Program Files\dotnet\sdk\8.0.303\

.NET workloads installed: [aspire] Installation Source: SDK 8.0.300, VS 17.12.35126.67, VS 17.12.35125.258 Manifest Version: 8.1.0/8.0.100 Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.1.0\WorkloadManifest.json Install Type: Msi

Host: Version: 8.0.7 Architecture: x64 Commit: 2aade6beb0

.NET SDKs installed: 6.0.132 [C:\Program Files\dotnet\sdk] 6.0.424 [C:\Program Files\dotnet\sdk] 7.0.120 [C:\Program Files\dotnet\sdk] 7.0.203 [C:\Program Files\dotnet\sdk] 7.0.317 [C:\Program Files\dotnet\sdk] 8.0.107 [C:\Program Files\dotnet\sdk] 8.0.206 [C:\Program Files\dotnet\sdk] 8.0.303 [C:\Program Files\dotnet\sdk] 8.0.400-preview.0.24324.5 [C:\Program Files\dotnet\sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 6.0.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 7.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 7.0.19 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 6.0.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 7.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 7.0.19 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 6.0.30 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 6.0.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 7.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 7.0.19 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 8.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found: x86 [C:\Program Files (x86)\dotnet] registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables: Not set

global.json file: C:\Users\andarno\source\repos\Library.Template\global.json

Learn more: https://aka.ms/dotnet/info

Download .NET: https://aka.ms/dotnet/download

[AArnott]

I also note that /p:NoWarn=MSB3982 added to dotnet workload restore is ignored. The warnings are still emitted.

[AR-May]

Team triage: @GangWang01 could you please try to repro, collect a binary log and take a look at this warnings?

[JaynieBai]

Repro and get the binlog CentralNode_dotnet_PID=14580_x64_BuildManager_Default.binlog.txt

[JaynieBai]

From workload log CentralNode_dotnet_PID.14580_x64_BuildManager_Default.binlog.txt , I see AnnotatedProjects Library.csproj and dir.proj have SkipGetTargetFrameworkProperties = true. So, it won't execute GetReferenceNearestTargetFrameworkTask to get the platform and platforms metadata. So, the warning MSB3982 from the task GetCompatiblePlatform is emitted when EnableDynamicPlatformResolution is true in the https://github.com/AArnott/Library.Template/blob/611f5abfb16c27ed2e2f1d72b4bbaf9a9dd81a7c/Directory.Build.props#L17

dotnet build binlog msbuild.build.binlog.txt. The Library.csproj project doesn't execute task GetCompatiblePlatform

[JaynieBai]

dotnet build /t:rebuild also emits the warning

When dotnet build /t:rebuild and dotnet workload, both of the processes execute the target _GetProjectReferencePlatformProperties that has the task GetCompatiblePlatform before rebuild and workload initial target.

[JaynieBai]

I also note that /p:NoWarn=MSB3982 added to dotnet workload restore is ignored. The warnings are still emitted.

When do the workload. the initial target is _GetRequiredWorkloads. It doesn't do the command switch analysis as msbuild. If want to suppress this warning. We can define the property NoWarn or MSBuildWarningsAsMessages in the project.

@JanKrivanek Could you help me have a look if there is something wrong with my understanding?

[JanKrivanek]

@JaynieBai - do you mean that dotnet workload restore does not pass through the /p commandline argument to the msbuild execution?

@joeloff - is the workload command expected to pass-through the args to the msbuild? If not - should it somehow indicate that unknown argument was used on commandline?

[baronfel]

Many CLI commands are implemented (or use data from) MSBuild evaluations and target executions. This specific command doesn't accept /p values and could possibly have its grammar locked down more. In general the SDK doesn't do a great job of 'insulating' the user from MSBuild when MSBuild is used as an implementation detail, and this is one more example of that IMO.

[JaynieBai]

@JaynieBai - do you mean that dotnet workload restore does not pass through the /p commandline argument to the msbuild execution?

Yes, from the log, I didn't find workload restore pass the /p argument to msbuild execution.

[JanKrivanek]

Applogies - I accidentaly didn't respond.

@AArnott - this is 'by design' for msbuild in a sense that the property parameter is not being passed to msbuild execution from sdk (the workaround would be to specify the property in the msbuild xml - but that might not be desirable).

sdk could improve by either erroring out on unrecognized parameter or by passing it thorugh to msbuild. The issue mover doesn't sem to work - so let me create a new issue in sdk repo and reference here

[JanKrivanek]

https://github.com/dotnet/sdk/issues/43355

[AArnott]

Why did you close this issue? The bug you filed against the SDK is unrelated to the original issue reported.

[JanKrivanek]

@AArnott - appologies - oversight on my side (I didn't notice orriginal issue was separate from the endo of discussion)

@JaynieBai - can you please look once again and elaborate more on the findings https://github.com/dotnet/msbuild/issues/10468#issuecomment-2277512458? I can see GetCompatiblePlatform being executed in the dotnet build binlog as well. What is the difference here? Thank you

[JaynieBai]

@AArnott - appologies - oversight on my side (I didn't notice orriginal issue was separate from the endo of discussion)

@JaynieBai - can you please look once again and elaborate more on the findings #10468 (comment)? I can see GetCompatiblePlatform being executed in the dotnet build binlog as well. What is the difference here? Thank you

@JanKrivanek dotnet workload has the GetCompatiblePlatform task and property SkipGetTargetFrameworkProperties = true in the dir.proj project. But dotnet build doesn't have the GetCompatiblePlatform being executed in the dir.proj project.

The warnings are from the GetCompatiblePlatform task in dir.proj.

[maridematte]

Team triage: @YuliiaKovalova will investigate this further.