Incorrect evaluation of 'Directory.Packages.props'

The logic for processing Directory.Packages.props in a central package versioning report does not follow the spec:

https://github.com/leonardochaia/dotnet-affected/blob/9893044cf8a026f2f7c700bfa8a7128e05126790/src/dotnet-affected/Domain/AffectedExecutor.cs#L102-L103

It assumes a single Directory.Packages.props can exist in a repo.

If there are multiple, and both have changed in the same run it will throw.

From Microsoft docs:

NuGet’s .props files automatically import a file named Directory.Packages.props if it’s found in the project folder or any of its ancestors.

I.E the first Directory.Packages.props file found in the project’s directory or any other folder up to the root (solution directory) is used. If a file is found and there are additional files in ancestor folders they are ignored by the build.

Usually, one will build nested Directory.Packages.props files like this:

<Project>

    <!-- First import top level package props... -->

    <Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory).., Directory.Packages.props))\Directory.Packages.props" />

    <!-- Override/Add with project local versioning -->

    <ItemGroup>
        <PackageVersion Include="System.Text.Json" Version="6.0.4" />
    </ItemGroup>
</Project>

Since MS Build Project instance is used to load the package props: https://github.com/leonardochaia/dotnet-affected/blob/9893044cf8a026f2f7c700bfa8a7128e05126790/src/dotnet-affected/Infrastructure/NugetHelper.cs#L26

I can only assume the only file we need to load is the one closest to the project folder and ignore (but not fail) others.

For the a 1st phase fix this will suffice.

It is however, not 100% accurate, but a bit more complex to perfect it… I’ll elaborate in a new comment below

[shlomiassaf]

There’s something I still don’t get tho. Once the Project is loaded, including the props/targets files, is there a way using MSBuild to “query which packages a project is referencing” (including DPP files, etc)?

Once a Project is loaded you have all the data you need, properies, metadata etc… all evaluated and unevaluated.

You have it all aggregated to the project instance, from all files, after loading them internally.

I already have a branch (in my fork) with a good workaround for the MS issue I opened, where I just use a single csproj file to evaluate all the things I need.

At the moment I still work directly with PackageReference and PackageVersion and I still need to check the propeties related to DPP, like if it’s disabled, etc… but in one single file.

I’ve also added there support for OverrideVersion and the check for disabling OverrideVersion.

I did not find the microsoft code/library that based on a project instance returns the list of resolved packages. It’s out there, it might be something for the future but either way, that will resolve the packages after evaluation, i.e. conditions will apply so it might not be the desired solution when we want to ignore confitions.

[leonardochaia]

Hey Shlomi! I am catching up with your comments & PR.

All can be avoided just by importing the csproj directly as a Project instance WILL load the DPP, Build.props, targets and what not… full, real resolutions.

This is great!! I ofc agree that we should leverage most we can to MSBuild and avoid having custom re-implementation of the spec.

There’s something I still don’t get tho. Once the Project is loaded, including the props/targets files, is there a way using MSBuild to “query which packages a project is referencing” (including DPP files, etc)?

Having a virtual FS for the git references we are comparing is awesome!! Taking a look at the PR now.