Discrepancy between build.cmd and IDE build

[KirillOsenkov]

When I type build.cmd to build the MSBuild repo on Windows it ends up with this command line:

/m /nologo /clp:Summary /v:minimal /nr:True /p:ContinuousIntegrationBuild=False /warnaserror /p:TreatWarningsAsErrors=true "C:\Users\kirill\.nuget\packages\microsoft.dotnet.arcade.sdk\1.0.0-beta.20580.3\tools\Build.proj" "/bl:C:\msbuild\artifacts\log\Debug\Build.binlog" "/p:Configuration=Debug" "/p:RepoRoot=C:\msbuild" "/p:Restore=True" "/p:DeployDeps=False" "/p:Build=True" "/p:Rebuild=False" "/p:Deploy=False" "/p:Test=False" "/p:Pack=False" "/p:IntegrationTest=False" "/p:PerformanceTest=False" "/p:Sign=False" "/p:Publish=False""

When I open MSBuild.Dev.sln in Visual Studio, some of these properties are not set, so the in-IDE behavior is slightly different. Specifically, projects always rebuild even if nothing has changed: this file: C:\msbuild\artifacts\obj\Microsoft.Build.Framework\Debug\net472\Microsoft.Build.Framework.AssemblyInfo.cs has an extra attribute ([assembly: System.Reflection.AssemblyMetadataAttribute("RepositoryUrl", "https://github.com/microsoft/msbuild")]) compared to the command-line build. It gets added because of a different default (GenerateRepositoryUrlAttribute = true in the IDE builds).

I think the default behavior for build.cmd should match as closely as possible the defaults picked by the build if you just do msbuild /r /m /bl with no extra properties. This way opening the solution in the IDE will result in the same builds instead of flip-flopping and competing with the command-line build and breaking incrementality.

[KirillOsenkov]

Actually I think this is because the difference is resolved SDK (3.1 in command-line case vs. 5.0 in the IDE case). 5.0 added a new attribute, so depending on which SDK you're using to build you'll get a different set of generated attributes in the AssemblyInfo.cs.

I think we can close this one then (it is expected that if you use different SDKs you might get slight discrepancies between builds like this).

[KirillOsenkov]

Turns out I had to set these environment variables to replicate the behavior of resolving 3.1.100:

PATH=C:\msbuild\.dotnet;%PATH%
DOTNET_INSTALL_DIR=C:\msbuild\.dotnet
DOTNET_MULTILEVEL_LOOKUP=0

Is there a file equivalent of setting these (such as an .rsp file?) so that the behavior we get in VS is identical to the build.cmd behavior?

The workaround is to set the two environment variables and open VS from that prompt to inherit that environment. Otherwise you'll keep getting little discrepancies as a result of vanilla VS choosing a different SDK.

[KirillOsenkov]

I've also filed dotnet/sdk#15149 because I literally spent whole day on this issue.

[rainersigwald]

I think the ideal solution would be dotnet/sdk#8254.

FYI @KathleenDollard -- here's another global.json-adjacent thing that would be made worse by ignoring it.

[KirillOsenkov]

Sigh, I keep wasting time on this, doing the same investigation over and over. After a few months I forget about this and start the whole investigation from scratch, and always come back to this issue.