Platform configuration is applied to other builds in batch scripts

[dn9090]

Issue Description

I'm not sure if it's a bug, intentional or if I forgot something - but the behavior of msbuild / dotnet build within batch scripts doesn't make sense to me.
I have a “release” batch script in which another batch script is called that builds a CPP project using msbuild. Then the “release” script simply uses dotnet build -c Release to first create a release build of a .NET Standard project and then dotnet pack to create the Nuget package.
The following folder structure is generated:

bin/
  x64/
    Release/
      myproject.1.0.0.nupkg
      netstandard2.0/
        myproject.dll
        ...

If the lines of the “release” script are executed manually in the console step by step, the following folder structure is created (which is also the expected result):

bin/
  Release/
    myproject.1.0.0.nupkg
    netstandard.2.0/
      myproject.dll
      ...

It looks as if msbuild is applying the platform configuration of the CPP build to the dotnet release build in the batch script, although I have not specified the platform anywhere.

Steps to Reproduce

Here are my scripts:
release.bat

CALL build.bat Release
CALL dotnet build NETPROJECT -c Release
CALL dotnet pack NETPROJECT
CALL docfx .\docfx.json

build.bat

SET VcVarsPath=%VSPath%\VC\Auxiliary\Build\vcvarsall.bat
CALL "%VcVarsPath%" x64 > nul 2>&1
[...]
IF "%Debug%"=="1" SET Configuration=Debug
IF "%Release%"=="1" SET Configuration=Release

CALL msbuild %Project% /p:Configuration=%Configuration% /p:Platform=x64

I execute the lines of the release.bat manually on the console:

> build.bat Release
> dotnet build NETPROJECT -c Release
> dotnet pack NETPROJECT

Expected Behavior

I expect the batch script to generate the same result as if I execute the lines manually.
I have also tried to reset the configuration with dotnet restore / dotnet clean - without success.

Actual Behavior

For some reason, the platform configuration is applied in all subsequent dotnet calls if msbuild was previously executed with a platform configuration (in a batch file).

Analysis

No response

Versions & Configurations

17.3.1.41501

[JanKrivanek]

Thank you for the report.

Please be aware that MSBuild is resolving properties values from environment variables (if the MSBuild script is dereferencing property, that is not explicitly defined while an env var with same name exists - it'll be used). This seems what is happening in your case - as you are defining env var with name Configuration

[dn9090]

Thank you for the report.

Please be aware that MSBuild is resolving properties values from environment variables (if the MSBuild script is dereferencing property, that is not explicitly defined while an env var with same name exists - it'll be used). This seems what is happening in your case - as you are defining env var with name Configuration

Thank you for your answer. Is there a way to prevent this? I find the order somehow strange. If no parameters are passed - okay makes sense (even if I would have preferred to name the variables MS_BUILD_CONFIGURATION) - but with CLI parameters I expected nothing to be pulled in.
The problem is that we set these variables in various (also non-msbuild build scripts). Removing them manually would be quite time-consuming for us.

[JanKrivanek]

Thank you for the report.
Please be aware that MSBuild is resolving properties values from environment variables (if the MSBuild script is dereferencing property, that is not explicitly defined while an env var with same name exists - it'll be used). This seems what is happening in your case - as you are defining env var with name Configuration

Thank you for your answer. Is there a way to prevent this? I find the order somehow strange. If no parameters are passed - okay makes sense (even if I would have preferred to name the variables MS_BUILD_CONFIGURATION) - but with CLI parameters I expected nothing to be pulled in. The problem is that we set these variables in various (also non-msbuild build scripts). Removing them manually would be quite time-consuming for us.

Unfortunately this would break some of the common targets shipped with SDK/VS.
We're preparing functionality that would help you check for violations in opt-in form ('BuildCheck', specifically BC0103

[JanKrivanek]

As for the mentioned feature - from .NET 9.0 (or 17.12 if you use msbuild.exe) you can opt in to the 'BuildCheck' on commandline via /check

The BC0103 is just suggestion level and scoped to user code - as this practice is still wide-spread.

In order to increase to severity and scope of check You'd need to add an .editorconfig file with something like:

[*.csproj]
build_check.BC0103.severity=warning
build_check.BC0103.scope=all

and then run your build with buildcheck opted in:

dotnet build /check

you'd then see something like:

  MyProj succeeded with 6 warning(s) (0.3s) → C:\tst\Release\net9.0\MyProj.dll
    C:\src\msbuild-2\artifacts\bin\bootstrap\core\sdk\9.0.200-preview.0.24523.19\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.props(49,11): warning BC0103: https://aka.ms/buildcheck/codes#BC0103 - Property is derived from environment variable: 'MSBuildExtensionsPath'. Properties should be passed explicitly using the /p option.
    C:\tst\obj\MyProj.csproj.nuget.g.props(7,5): warning BC0103: https://aka.ms/buildcheck/codes#BC0103 - Property is derived from environment variable: 'USERPROFILE'. Properties should be passed explicitly using the /p option.
    C:\Program Files\dotnet\sdk\9.0.100-rc.2.24474.11\Current\Microsoft.Common.props(84,119): warning BC0103: https://aka.ms/buildcheck/codes#BC0103 - Property is derived from environment variable: 'MSBuildUserExtensionsPath'. Properties should be passed explicitly using the /p option.
    C:\Program Files\dotnet\sdk\9.0.100-rc.2.24474.11\Current\Microsoft.Common.props(102,20): warning BC0103: https://aka.ms/buildcheck/codes#BC0103 - Property is derived from environment variable: 'Configuration'. Properties should be passed explicitly using the /p option.
    C:\Program Files\dotnet\sdk\9.0.100-rc.2.24474.11\Microsoft.Common.CurrentVersion.targets(2579,5): warning BC0103: https://aka.ms/buildcheck/codes#BC0103 - Property is derived from environment variable: 'LOCALAPPDATA'. Properties should be passed explicitly using the /p option.
    C:\Program Files\dotnet\sdk\9.0.100-rc.2.24474.11\Microsoft.Common.CurrentVersion.targets(6846,5): warning BC0103: https://aka.ms/buildcheck/codes#BC0103 - Property is derived from environment variable: 'MSBuildExtensionsPath32'. Properties should be passed explicitly using the /p option.

Which gives you info about what all properties in your build are sourced from env

[JanKrivanek]

@dn9090 I just wanted to check if there is anything further you think should be done on MSBuild side?
I'm setting a flag that will autoresolve the issue after couple weeks if there is no response - but wanted to first give an explicit heads up on this.