[GreymanTheGrey]

Something like this would be a game changer for my workplace.

This particular issue is a huge bugbear for our team of 50'ish developers in a .NET development environment, working on a large product with a lot of shared code/models/etc that often has to be updated at the same time as application logic.

It is astonishing to me that MS haven't addressed this issue with NuGet workflow and its hostility towards developers working on internal code.

[accoil]

You can use Directory.Build.targets, and Directory.Build.props to have shared build targets/properties—including package references. When building MSBuild will keep checking parent directories until it finds those files and imports them.

See: https://docs.microsoft.com/en-us/visualstudio/msbuild/custom...

I don't use them for package references myself, but this blog post has some information on how you'd do that: https://www.mytechramblings.com/posts/centrally-manage-nuget...

[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.

[asp_hornet]

100% agree. These pain points eventually broke me and I just left .net for Go