Incorrect evaluation of 'Directory.Packages.props'
See original GitHub issueThe logic for processing Directory.Packages.props
in a central package versioning report does not follow the spec:
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
Issue Analytics
- State:
- Created a year ago
- Comments:7 (7 by maintainers)
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
andPackageVersion
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 disablingOverrideVersion
.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.
Hey Shlomi! I am catching up with your comments & PR.
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.