How to detect transitive dependency versions to avoid issues.

[robertson-bauercontrols]

Hi,

This is an issue discussed on here quite a bit, but my question isn't the standard 'what to do', but more 'how do I detect this is happening'.

Our codebase is about 500 project spread across 8ish solutions. We are having the following setup

WindowA depends on CSVHelper, JsonSerializer, OPCFoundation, etc.
WindowB depends on Entities, System.Collections, etc.

These nuget packages have transitive dependencies on several dlls, but in my case, it's System.Buffers. The issue we had was that whatever the last project compiles, is what dumped the version of System.Buffers it needed.

The correct solution, I believe, is to use <CentralPackageTransitivePinningEnabled>true</CentralPackageTransitivePinningEnabled> with CVPM, and specify <PackageVersion Include="System.Buffers" Version="4.5.1" Pin="true"/> in the Directory.Packages.Config . This works!

So, a few questions:

1. Is what I did above the best-practice for fixing my issue?
2. My main question: How do I find problems like these at build-time? The only reason we knew this was a problem was a runtime failure by one of our windows when the attempted to connect to a server. Do I have to keep a log of every single dll I copy into output, with its version, and compare for bad versions getting copied?

Thanks for any feedback others have :)

[TheXenocide]

A while back I had to do an analysis across a bunch of separate solutions that reference each other and used a combination of the Microsoft.Build and NuGet.ProjectModel nuget packages to write a LINQPad script. The script used the Microsoft.Build package to analyze PackageIds (we use the Pack target to create internal packages) and PackageReferences to determine which of our own projects reference each other across solution boundaries. It then used NuGet.ProjectModel to load the data in each project's obj\project.assets.json file (which requires that every solution had at least executed a NuGet restore). I found the most reliable way to detect conditions which required manual explicit overrides for transitive dependencies was to collect all the versions of any given package that were actually restored, as well as all the minimum versions requested by each package in the transitive chain (project.assets.json knows which versions every package restored wants, independent of which version is loaded). I found that the most reliable way to detect issues by finding when any given project restored a version of a given package that was lower than the "highest minimum version" requested by any other package.

I don't have quite enough time to extract the logic out, but here are some snippets that might help point you to the pieces of data I found helpful:

// this was used to load the project.assets.json file
LockFile = LockFileUtilities.GetLockFile(Path.Combine(Path.GetDirectoryName(FullPath), @"obj\project.assets.json"), NuGet.Common.NullLogger.Instance)

// this is essentially the "minimum request version" of transitive dependencies
LockFile.Targets[...].Libraries[...].Dependencies[...].VersionRange.MinVersion

// this is the version that was restored by the project
LockFile.Libraries[...].Version

I will say there is a new feature that looks like it would help with this (CentralPackageTransitivePinningEnabled, as part of Central Package Management). That feature still requires defining an explicit version for packages that need to be transitively overridden so hopefully this logic will still help.

[robertson-bauercontrols]

I updated my original post. Ironically (or not ironically), I had tried using CentralPackageTransitivePinningEnabled, and it didn't solve my problem, I as still getting bad versions of System.Buffers.

I had missed something through, my visual studio 2022 was at 17.1.x, and CentralPackageTransitivePinningEnabled only worked in 17.2+. Once I did the upgrade, and now everything's working awesome!

Thanks for your description of the Linqpad script you wrote. My build setup seems very similar to yours. I'd love to avoid doing (what seemed to be a lot of) the work of writing that as well. I'll see if some magic bullet comes up, but I have a feeling I'll be doing what you did.

[TheXenocide]

Yeah, the pinning feature in CPM would really have saved us a ton of effort 😅 though there's still the trouble of finding the bad versions that haven't been pinned yet which often times (for us, anyway) show up as runtime issues instead of at compile time. That's where the script comes in for us. Right now we tend to do the analysis manually, but I dream of a day where we can better automate the analysis and detect/make recommendations during CI builds.