dotnet sln builds using incorrect project configuration for transitive dependencies

Steps to reproduce

mkdir repro &&
cd repro &&
dotnet new classlib -o projA &&
dotnet new classlib -o projB &&
dotnet add projB reference projA &&
dotnet new sln &&
dotnet sln repro.sln add projB &&
dotnet build repro.sln -c Release

Expected behavior

Should build projA and projB using Release configuration.

Actual behavior

projA is built using Debug and projB is built using Release.

$ dotnet build repro.sln -c Release
Microsoft (R) Build Engine version 15.9.20+g88f5fadfbe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restoring packages for C:\Users\eirik.tsarpalis\devel\private\repro\repro\projB\projB.csproj...
  Restore completed in 52.68 ms for C:\Users\eirik.tsarpalis\devel\private\repro\repro\projA\projA.csproj.
  Restore completed in 210.78 ms for C:\Users\eirik.tsarpalis\devel\private\repro\repro\projB\projB.csproj.
  projA -> C:\Users\eirik.tsarpalis\devel\private\repro\repro\projA\bin\Debug\netstandard2.0\projA.dll
  projB -> C:\Users\eirik.tsarpalis\devel\private\repro\repro\projB\bin\Release\netstandard2.0\projB.dll

The fact that this behaviour is incorrect is corroborated by the fact that project-driven builds do not exhibit this behaviour:

$ dotnet build projB/ -c Release
Microsoft (R) Build Engine version 15.9.20+g88f5fadfbe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 54.32 ms for C:\Users\eirik.tsarpalis\devel\private\repro\repro\projB\projB.csproj.
  Restore completed in 54.32 ms for C:\Users\eirik.tsarpalis\devel\private\repro\repro\projA\projA.csproj.
  projA -> C:\Users\eirik.tsarpalis\devel\private\repro\repro\projA\bin\Release\netstandard2.0\projA.dll
  projB -> C:\Users\eirik.tsarpalis\devel\private\repro\repro\projB\bin\Release\netstandard2.0\projB.dll

Environment data

$ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   2.2.101
 Commit:    236713b0b7

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.2.101\

Host (useful for support):
  Version: 2.2.0
  Commit:  1249f08fed

[rainersigwald]

I believe this is a longstanding intentional behavior in solution builds, so I’d be curious to see a case where it works as you expect, @aawadall.

The idea behind the behavior is to allow “solution configurations” that differ from “project configurations”. For example, using the Visual Studio UI, you can configure a solution such that a specific project is built in “Release” configuration even when the solution overall is set to “Debug” (perhaps because Debug builds of that project have bad performance characteristics or something).

To support that, projects don’t directly pass their own configuration down to their dependencies when building in a solution. Instead, they do a lookup inside the solution to see what the corresponding configuration is for the reference, given their own configuration.

When the referenced project is not in the solution, the configuration assignment has a choice: it can either let the current project’s configuration flow as usual (flow if explicitly specified; take default if default is being built) or use the referenced project’s default configuration. The latter is the default, but there’s an explicit control for this–the property ShouldUnsetParentConfigurationAndPlatform. If you want configurations to flow, you must set

<PropertyGroup>
 <ShouldUnsetParentConfigurationAndPlatform>false<ShouldUnsetParentConfigurationAndPlatform>
</PropertyGroup>

in your project(s) (or in a Directory.Build.props for your repo).

[cataggar]

This bites me every few months. I’d love to see the behavior flipped for net7.