`dotnet build` treats dependencies differently when targeting .sln vs .csproj

[pyrrho]

Describe the bug

When executing dotnet build SomeProject.csproj, the command line option --configuration Release will be applied to all ProjectReferences listed in SomeProject.csproj.

When executing dotnet build SomeSolution.sln, the command line option --configuration Release will only be applied to Projects listed in SomeSolution.sln -- projects pulled in through .csproj ProjectReferences will be built with the Debug configuration.

I expect the build configuration isn't the only option that won't be forwarded, but I've not done any kind of exhaustive search through possible MSBuild options.

To Reproduce

Initialize two classlib projects, and one console project. Add both classlibs to the console as project references.

dotnet new console  -o ExecProj
dotnet new classlib -o LibraryA
dotnet new classlib -o LibraryB
dotnet add ExecProj reference LibraryA
dotnet add ExecProj reference LibraryB

Create a .sln, including the console project and only one of the classlibs.

dotnet new sln -n Solution
dotnet sln add ExecProj
dotnet sln add LibraryA

Clean all three projects, and build the console project in Release mode by directly targeting the relevant .csproj file.

dotnet clean ExecProj
dotnet clean LibraryA
dotnet clean LibraryB
dotnet build ExecProj/ExecProj.csproj --configuration Release

Observe that both classlibs output files to **/bin/Release/**.

Clean all three projects, and build the console project in Release mode by referencing the.sln.

dotnet clean ExecProj
dotnet clean LibraryA
dotnet clean LibraryB
dotnet build Solution.sln --configuration Release

Observe that the classlib that is not referenced in the .sln output files to **/bin/Debug/**, and that the classlib that is referenced in the .sln output files to **/bin/Release/**.

Exceptions (if any)

None. Though that may be an issue?

Description (cont.)

I'm aware that this may be the intended behavior for solution files. I found this issue while trying to shave off a few minutes from my company's CI pipeline, specifically while attempting to dynamically generate a .sln based off of the list of projects directly modified in the given PR. I expect that my specific use case is well outside the intended scope for solution files, and I don't expect support for my experiments.

This behavior was very surprising, though, and took most of a day to hone in on because a restore, build, test chain will exit successfully on such a dynamically generated .sln, but attempting a publish may or may not fail. If the published .csproj references projects that are not included in the given solution, it will (correctly) fail to find files in **/bin/Release/** because those non-referenced projects were built into **/bin/Debug/**. When I was lucky enough to include all of the relevant projects in the generated .sln, the publish step succeeded.

If this is the intended behavior of dotnet build against solutions, I would still hope that some modification could be made to make it easier to observe and track down ProjectReferences that are not included in the solution. Perhaps a cli flag could be used to select the out-of-solution dependency resolution strategy, or a warning (that could then be elevated to an error) could be added.

Or maybe such a feature already exists, and I just missed it while I was digging. That would be fantastic.

Further technical details

% dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.300
 Commit:    8473146e7d

Runtime Environment:
 OS Name:     pop
 OS Version:  22.04
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /home/drew/.dotnet/sdk/6.0.300/

Host (useful for support):
  Version: 6.0.5
  Commit:  70ae3df4a6

.NET SDKs installed:
  3.1.419 [/home/drew/.dotnet/sdk]
  6.0.300 [/home/drew/.dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.25 [/home/drew/.dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.5 [/home/drew/.dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.25 [/home/drew/.dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.5 [/home/drew/.dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

[baronfel]

When you build a solution, a 'meta project' is generated from the solution and that is what's actually built. Here's the meta project from the Release build you describe above (thanks for the CLI-based repro, that made this very easy to dig into!):

generated-sln.zip

The key is this section of the ResolveProjectReferences target:

    <!--
        Build referenced projects when building from the command line.
        -->
    <MSBuild
        Projects="@(_MSBuildProjectReferenceExistent)"
        Targets="%(_MSBuildProjectReferenceExistent.Targets)"
        BuildInParallel="$(BuildInParallel)"
        Properties="%(_MSBuildProjectReferenceExistent.SetConfiguration); %(_MSBuildProjectReferenceExistent.SetPlatform);  %(_MSBuildProjectReferenceExistent.SetTargetFramework)"
        Condition="'%(_MSBuildProjectReferenceExistent.BuildReference)' == 'true' and '@(ProjectReferenceWithConfiguration)' != '' and '$(BuildingInsideVisualStudio)' != 'true' and '$(BuildProjectReferences)' == 'true' and '@(_MSBuildProjectReferenceExistent)' != ''"
        ContinueOnError="$(ContinueOnError)"
        RemoveProperties="%(_MSBuildProjectReferenceExistent.GlobalPropertiesToRemove)$(_GlobalPropertiesToRemoveFromProjectReferences)">

      <Output TaskParameter="TargetOutputs" ItemName="_ResolvedProjectReferencePaths" Condition="'%(_MSBuildProjectReferenceExistent.ReferenceOutputAssembly)'=='true' or '$(DesignTimeBuild)' == 'true'"/>
      <Output TaskParameter="TargetOutputs" ItemName="%(_MSBuildProjectReferenceExistent.OutputItemType)" Condition="'%(_MSBuildProjectReferenceExistent.OutputItemType)' != ''"/>

    </MSBuild>

The Configuration property is being stripped by the RemoveProperties build property, which is set when running the ResolveNonMSBuildProjectOutput task. @dotnet/msbuild-writers is this something that users have influence over? it would be nice to remove a bit of bookkeeping from the solution.

@pyrrho in the interim you can get around this by making sure your solutions are in sync with your project layout. If you don't have a lot of customizations you canuse tools like slngen or nosln to create the solution file in an automated way.

[worldspawn]

slngen works a treat. Thanks