No. Imagine you have a nuget package your solution relies on. If you want to test a change to that nuget you would need to change the nuget reference to a local project reference or publish locally.

Imagine if you could create a file on the solution level that uses the source code in a directory instead of the nuget without affecting the csproj, sln or nuget references

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.

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

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.

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.

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

So a way to easily temporarily override the dependency reference to use a local project rather than a NuGet package? That does sound quite useful. I think this can be done relatively easily in a csproj with conditional references though?

> So a way to easily temporarily override the dependency reference to use a local project rather than a NuGet package?

Yes. Great for debugging too.

> I think this can be done relatively easily in a csproj with conditional references though?

Maybe, but you’d have to do this manually for all the projects in a solution. This is built into the tooling and produces a .gitignore-able file

Project files are a semi complex file format specifying a lot of configuration that a given project has. One project file has no bearing on another project.

Workspaces are a convention built into the language that requires no configuration. This convention applies broadly across projects equally, using identical rules for all projects. You need to download/checkout your repos in a certain way, but then they all play together.

Yes

It most definitely isn’t