Ftyjtk

I've tried to look at many of the questions asked here about it, but none is exactly like my set-up.

Also, this issue is NOT directly related to Nuget, but it might be part of the solution.

I have a project which consists of a few solutions. All of the projects in those solutions use the same output path.

Example:

-Root

--Solution1

--Solution2

--Solution3

--OutputForAllProjectsInAllSolutions

I want to use NuGets in those solutions. The problem is if I'll use different version of the same NuGet package in each solution, then the each solution will override it's predecessor's reference dlls.

I was thinking of a solution, but I don't know if it's possible and how.

Something like:

-Root

--Solution1

--Solution2

--Solution3

--PackagesFolderForAllSolutions // can be done with repositoryPath right?

--OutputForAllProjectsInAllSolutions

---NugetPackageVersion1

---NugetPackageVersion2

---NugetPackageVersion3

Is it a possible? Is it a good solution? How to do it?
If not, any better suggestions?

Thanks in advance.

• 
  EDIT: I wish I could use 1 solution for all, but it's legacy code, and it has too much complexity.

The setup is 1 source-code repository with multiple solutions.

The real question appears to be "how can I make sure all projects use the same version of a dependency", but it's unclear to me if you proposed using a shared packages folder in order to save disk space. Using a shared folder will not solve the multiple versions problem, you'll just end up with a packages folder with multiple versions of a package, but maybe you want to save disk space, so I'll answer that as a separate question. I'm going to avoid the opinionated 'is it a good solution', but in my opinion the "better solution" you asked for is to migrate all projects to PackageReference and use the solution I give below. Also considering using a single solution, but that's unrelated to nuget package versions.

How can I make sure all my projects are using the same version of a NuGet dependency

• Code in multiple source control repositories

If your code is spread across multiple source code repositories, then if your cross-project references are internal nuget packages, the projects that depend on projects from other repos via a nuget package will get external nuget dependencies transitively, so simply avoid upgrading nuget packages in your downstream projects. Upgrading will mean upgrading in your upstream project, generate a new nuget with a higher dependency version, generating a package, then updating the version of your internal package in your downstream project. It's a lot of effort, which is why I dislike having applications/systems spread across multiple source code repositories. There may still be reasons to do it which outweigh the costs, and to me that's what engineering is all about, dealing with trade-offs.

• Code in single repository. Multiple solutions, NuGet packages via packages.config
  

If your code is in a single repository, at least one of your projects use packages.config and your application is spread across multiple solutions, then there's still going to be a reasonable amount of manual work, but the fewer packages.config projects there are, the less work there will be. You could use the method for a single solution application, and do it multiple times for each solution.

• One solution, NuGet packages via packages.config
  

Right click the solution, select "Manage NuGet Packages for Solution", then go to the Consolodate tab.

• NuGet packages via PackageReference
  

If you're using PackageReference, it doesn't matter if your repo has a single solution or multiple solutions. You can create a MSBuild props file with your NuGet package versions. As an example, have a look at this ASP.NET Core example. If you put these properties in a file named Directory.Build.props at the repo root, newish versions of MSBuild should (I've never tested it myself) import it automatically. Otherwise you'll need to edit all your project files to include an import to the props file. Then you edit the project files and change the version to use the MSBuild property. Again, example from the ASP.NET Core repo. Downside is that you can no longer use Visual Studio to update the package versions, but you can still use it to check for new versions and see what the newest versions are.

If your application has multiple repos, and multiple projects are using PackageReference, you can look into putting the props file in a git submodule, or something equivalent for your source control system.

In conclusion

I strongly recommend migrating from packages.config to PackageReference, and then you can use a MSBuild props file to automatically keep all projects using the same version of each dependency.

Can I reduce disk space by using a single packages folder for multiple solutions

Firstly, if all your projects used PackageReference, this wouldn't be an issue because NuGet does not copy PackageReference packages into solution folders, so there's even less disk usage than using packages.config with a shared packages folder, because you're still going to have one copy in the global packages folder and another in the solution packages folder.

But if you can't/won't migrate to PackageReference, then yes, as you asked in your question, you can use a nuget.config file at the root level to set <repositoryPath>packages</repositoryPath> to make all the solutions use the same packages folder at the root level, as long as the solution folders don't have their own nuget.config file that overrides the setting. You can change packages to anything you want, but I discourage using ..anything because I hate it when projects write files outside of their repository root.