真正的问题似乎是“我如何确保所有项目都使用相同版本的依赖项”,但我不清楚您是否建议使用共享包文件夹以节省磁盘空间。使用共享文件夹并不能解决多个版本的问题,您最终会得到一个包含多个版本的包的包文件夹,但也许您想节省磁盘空间,所以我将作为一个单独的问题来回答。我将避免固执己见的“这是一个好的解决方案”,但在我看来,您要求的“更好的解决方案”是将所有项目迁移到 PackageReference 并使用我在下面给出的解决方案。也在考虑使用单一解决方案,但这与 nuget 包版本无关。
如何确保我的所有项目都使用相同版本的 NuGet 依赖项
如果您的代码分布在多个源代码存储库中,那么如果您的跨项目引用是内部 nuget 包,则通过 nuget 包依赖来自其他存储库的项目的项目将传递地获得外部 nuget 依赖项,因此只需避免升级下游项目中的 nuget 包。升级将意味着在您的上游项目中升级,生成具有更高依赖版本的新 nuget,生成包,然后在下游项目中更新内部包的版本。这需要付出很多努力,这就是为什么我不喜欢将应用程序/系统分布在多个源代码存储库中的原因。这样做可能仍然有超过成本的理由,对我来说,这就是工程的全部意义所在,需要权衡取舍。
- 单个存储库中的代码。多种解决方案,NuGet 包通过
packages.config
如果您的代码位于单个存储库中,至少您的一个项目使用packages.config,并且您的应用程序分布在多个解决方案中,那么仍然会有合理数量的手动工作,但packages.config 更少有项目,工作量就会减少。您可以将该方法用于单个解决方案应用程序,并对每个解决方案执行多次。
- 一个解决方案,NuGet 包通过
packages.config
右键单击解决方案,选择“管理解决方案的 NuGet 包”,然后转到“合并”选项卡。
- NuGet 包通过
PackageReference
如果您使用的是 PackageReference,那么您的存储库是否具有单个解决方案或多个解决方案都没有关系。你可以使用你的 NuGet 包版本创建一个 MSBuild 道具文件。例如,看看这个ASP.NET Core example。如果您将这些属性放在 repo 根目录下名为 Directory.Build.props 的文件中,则 MSBuild 的新版本应该(我自己从未测试过)自动导入它。否则,您需要编辑所有项目文件以包含对 props 文件的导入。然后编辑项目文件并更改版本以使用 MSBuild 属性。再次,example from the ASP.NET Core repo。缺点是您不能再使用 Visual Studio 来更新包版本,但您仍然可以使用它来检查新版本并查看最新版本是什么。
如果您的应用程序有多个 repos,并且多个项目正在使用 PackageReference,您可以考虑将 props 文件放在 git 子模块中,或与您的源代码控制系统等效的东西中。
总结
我强烈推荐migrating from packages.config to PackageReference,然后你可以使用一个MSBuild props 文件来自动保持所有项目使用相同版本的每个依赖项。
我可以通过对多个解决方案使用单个包文件夹来减少磁盘空间
首先,如果您的所有项目都使用PackageReference,这不会成为问题,因为 NuGet 不会将 PackageReference 包复制到解决方案文件夹中,因此与使用 packages.config 和共享包文件夹相比,磁盘使用量甚至更少,因为您仍然会在全局包文件夹中拥有一个副本,在解决方案包文件夹中拥有另一个副本。
但是,如果您不能/不会迁移到 PackageReference,那么是的,正如您在问题中所问的那样,您可以使用根级别的 nuget.config 文件来设置 <repositoryPath>packages</repositoryPath> 以使所有解决方案都使用只要解决方案文件夹没有自己的覆盖设置的nuget.config 文件,根级别的相同包文件夹即可。您可以将packages 更改为您想要的任何内容,但我不鼓励使用..\anything,因为当项目在其存储库根目录之外写入文件时,我讨厌它。