Global msbuild properties from `Directory.Build.rsp` file are not respected in VisualStudio

[olgolo]

Visual Studio Version

2022

Summary

Global msbuild properties from Directory.Build.rsp file are not respected in VisualStudio. It causes missing parity of build results compared to msbuild console build.

Steps to Reproduce

1. Create Directory.Build.rsp in empty folder with this content:

   /p:Platform=x64
   

2. Create new project in that folder

   dotnet new classlib
   

3. Open project in VisualStudio
4. Build with VisualStudio UI.
5. Observe that targets are placed in

   bin\Debug\net6.0

6. Build from VisualStudio built-in terminal (Developer Console) with command:

   msbuild
   

7. Observe that the targets are placed to

   bin\ x64 \Debug\net6.0

Expected Behavior

VisualStudio build should produce same results as msbuild. It should provide parity for binaries it generates.

User Impact

CloudBuild used by our team requires global Platform property to be set, and uses x86 by default. So users are forced to use some global Platform property. To have local build parity with CloudBuild , Directory.Build.rsp file is created to set global Platform property. But this causes problems when debugging projects locally in VisualStudio, as well as packaging and publishing from it. VisualStudio disregards the binaries produced by msbuild (which are placed in bin\x64\Debug), rebuilds the project to recreate binaries in its own folder (bin\Debug) and fails to properly build and binplace binaries from referenced projects (because of another bug when VisualStudio ignores some msbuild definitions and fail to binplace some files), and eventually build fails. It just blocks the developers from use tooling for local developing. And it is not possible to workaround by building with msbuild from console, as VisualStudio ignores the binaries msbuild has produced and tries creating its own during packaging / publishing from UI. For now as a mitigation I removed /p:Platform=x64 from Directory.Build.rsp to unblock local team development. But now we have discrepancy between CloudBuild and local build, only hoping different global Platform parameter doesn't cause any discrepancy in produced binaries.

[tmeschter]

Possibly an issue at the CPS level?

[tmeschter]

Next step: follow up with CPS team.

[rainersigwald]

MSBuild response files apply only to MSBuild.exe and dotnet build invocations and do not apply to Visual Studio or any other process that uses the MSBuild API, so I think there's no bug here.

[kvenkatrajan]

@olgolo does your team have a workaround for this? This is working as per design at the moment and requires an enhancement to support rsp files

[olgolo]

@kvenkatrajan Nope. No workaround. I chose the least bad option, and don't set Platform in rsp file at all. CloudBuild may now produce a different build, as can't avoid setting global Platform property and using amd64 in our case.

[msedi]

I agree. This is really a bit annoying that MSBuild has so many switches that cannot be used from within Visual Studio IDE. For example I want to have a performancesummary at the end of the build which is not available in the IDE. To get it I have to get out of Visual Studio and use msbuild.exe externally.