Directory.Build.props should be imported before SDK props do anything

Using a Directory.Build.props file is one way we’ve told people to set properties before the common props run (see https://github.com/Microsoft/msbuild/issues/1603). However, Directory.Build.props is currently evaluated after Microsoft.NET.Sdk.props, which means setting some properties such as the Configuration or Platform in Directory.Build.props leads to inconsistent results, as there are other default property values which are based on them in Microsoft.NET.Sdk.props.

A fix to this would be to duplicate the logic from MSBuild that imports Directory.Build.props in the SDK targets, and then set ImportDirectoryBuildProps to false so that the common props don’t try to import it again.

This would be a breaking change for projects that rely (likely accidentally) on the current behavior, so we’d need to assess the compat risk of this change.

[rainersigwald]

I think it generally makes sense for an SDK to pull in d.b.props first and disable the common.props import. The idea of d.b.props is that it’s imported early. In the (old) default template, the common.props import was the first line, and the d.b.props import is very early in common.props–so d.b.props in the old world is basically first.

If we wind up making the core SDK a package (https://github.com/Microsoft/msbuild/issues/1686), we could separate out the d.b.props import into its own file so it could be more easily called by an SDK. Then the pattern for sdks could be

  <Import Project="Directory.Build.props" Sdk="Core"  />
  <Import Project="$(MSBuildThisFileDirectory)..\build\Microsoft.NET.Sdk.props"  />
  <Import Project="Microsoft.Common.props" Sdk="Core" />

It’s unfortunate that this would be a “standard pattern” rather than “done for you” but I don’t see a way around it that keeps explicit, ordered imports.

[rainersigwald]

That’s up to the Sdk. MSBuild’s evaluation order constraints make this complicated–usually you want to set some stuff early and some stuff after common.props. We can’t disconnect the directory.build.props import from common.props (it has to be somewhere). If it’s not in the right place for Microsoft.NET.Sdk, there are options:

• Change the relative import order in this SDK (as Jeff pointed out): https://github.com/dotnet/sdk/blob/b76e22d01bd8ce8ce0b0997a6800e804986bf29c/src/Tasks/Microsoft.NET.Build.Tasks/sdk/Sdk.props#L18-L19. Probably infeasible due to other property settings.
• Use the escape hatch common.props provides to do the d.b.props import at a time of your own choosing.
• Define a different pattern and import that instead (please don’t do this).

This is a limitation of the ordered-evaluation + import-whole-files + extensibility nature of MSBuild. We could change the order of imports but that only postpones the problem. We could shard into more files, but that pushes complexity into other layers (it’d be unpleasant if SDK.props had to import a dozen files from common in the right relative order, just to allow the possibility of avoiding this problem.