Default Configuration property set up later than Directory.Build.props is used

[starosta33]

Issue Description

Default Configuration property is set up later than Directory.Build.props is used

Steps to Reproduce

For example this setup in Directory.Build.props won't work using just dotnet build as Configuration is still empty string. Using dotnet build -c Debug everything works properly.

<Project>
  <PropertyGroup>
    <TargetFrameworks Condition=" '$(Configuration)' != 'Debug' ">net48;net9.0</TargetFrameworks>
    <TargetFrameworks Condition=" '$(Configuration)' == 'Debug' ">net48</TargetFrameworks>
  </PropertyGroup>
</Project>

Expected Behavior

Configuration is set to default value (e.g. Debug) in Directory.build.props when not specified explicitly

Actual Behavior

Configuration is an empty string in Directory.build.props when not specified explicitly

Analysis

No response

Versions & Configurations

No response

[KalleOlaviNiemitalo]

This is somewhat documented in https://learn.microsoft.com/en-us/visualstudio/msbuild/customize-by-directory?view=vs-2022#import-order:

Directory.Build.props is imported early in Microsoft.Common.props, and properties defined later are unavailable to it. So, avoid referring to properties that aren't yet defined (and will evaluate to empty).

After Microsoft.Common.props sets the default Configuration property, it imports $(CustomAfterMicrosoftCommonProps). So you could perhaps make Directory.Build.props set the CustomAfterMicrosoftCommonProps property and point it to a file that then reads the Configuration property and sets TargetFrameworks. But I'm not sure whether TargetFrameworks is already read before that. Presumably not, because TargetFrameworks is designed to be set in project files.

[KalleOlaviNiemitalo]

I don't expect that MSBuild will be changed to set the default Configuration property already before Directory.Build.props is imported. Such a change would have a high risk of breaking the build systems of existing projects.

IIRC, there were plans for a BuildCheck that would warn if MSBuild changes the value of a property that has already been read. I think that would warn about Directory.Build.props reading the Configuration property before Microsoft.Common.props sets it. Perhaps that warning could then link to a documentation page that explains how to use CustomAfterMicrosoftCommonProps to delay the Configuration read.

[JanKrivanek]

As @KalleOlaviNiemitalo mentioned - this is by design behavior.

As for diagnosability: In this specific case the property is unset at the point of referencing it - so BC0201 - Usage of undefined would catch this.

I'm currently not aware of ticket for "Property changed after it was referenced" - it definitely would be doable, but currently wouldn't make it into limited scope we have for this topic.