Directory.Build.props is ignored on target framework resolution

[Inok]

When Buildalizer tries to resolve target framework of a project and to choose an appropriate MSBuild version (Core vs .NET Framework), it reads target framework from csproj file. The problem is, we set target framework globally in a single Directory.Build.props file instead of configuring it at all csproj files. When Buildalizer doesn't know target framework, it always chooses .NET Framework version of MSBuild, ignoring the fact that our projects targets .NET 5. The build still works, so maybe there is no difference between those MSBuild versions and the issue is minor. But it leads us to another problem described at #165

[daveaglick]

That's a good find. Even if the build is working for your project (sometimes the differences between the Framework and Core MSBuild don't come into play), there are definitely times when this will result in a bad build.

[leonardochaia]

Hi. Side question, is there a way to know that a project has received any configuration from Directory.Build.props?

I'm considering using this package under the hood for dotnet-affected Supporting which projects are affected by changes made to a Directory.Build.props is a desired feature.

Regards, Leo.

[daveaglick]

is there a way to know that a project has received any configuration from Directory.Build.props

Probably not, at least not without some additional work. Buildalyzer is primarily aimed at capturing what gets sent to the Csc (or other language compiler) task. To do that it hooks MSBuild and logs MBuild events, so other information is going to be flowing through that stream, but at the moment we don't really capture or process any of it.

If we were to expand what gets captured it would probably need to happen here: https://github.com/daveaglick/Buildalyzer/blob/main/src/Buildalyzer/Logging/EventProcessor.cs

[leonardochaia]

Hi @daveaglick , thanks for the link. I did some debugging and I discovered there are properties for DirectoryBuildPropsPath already that includes the path when a Directory.Build.props file is present. I think that'll be enough for my use case.

For the record: DirectoryBuildPropsPath, DirectoryBuildTargetsPath, DirectoryPackagesPropsPath