[GreymanTheGrey]

The links you've provided more deal with how to keep NuGet package versions consistent across multiple projects within a solution. While this does solve an issue, it is not the problem being discussed.

Package version consistency is certainly an issue of merit and deserves attention, however for our company's use case is a minor bugbear in comparison to the issue of package references (for build) vs source or project references (for development) in large codebases that lean heavily on shared dependencies.

[accoil]

Ah yes! I completely the parent's point. I would actually like something like that.

My current approach is to use a directory.build.props file in the folder where I clone into (i.e. outside of all the repos), and use it to set the package output path to a local folder and timestamp the package version. That way every build creates a new package to test locally, but I still have to update the references in the dependent projects when testing (and build everything separately).

Not particularly happy with it, but I don't have to manage that many shared dependencies either.

I wonder if a precompile target has enough access to tinker with the references? I.e. remove items from the PackageReferences item group, and create corresponding ProjectReference items. Probably will need to also call the MSBuild build task on those projects too so they can have a fresh build in case any changes have been made in them too.

But yes, it would be great if Microsoft supplied something for that.