【问题标题】:Using NuGet on multiple solutions project with the same output path在具有相同输出路径的多个解决方案项目上使用 NuGet
【发布时间】:2018-11-18 10:27:22
【问题描述】:

我已经尝试查看这里提出的许多问题,但没有一个与我的设置完全一样。

此外,此问题与 Nuget 没有直接关系,但它可能是解决方案的一部分。

我有一个项目,其中包含几个解决方案。这些解决方案中的所有项目都使用相同的输出路径。

例子:

-Root
--Solution1
--Solution2
--Solution3
--OutputForAllProjectsInAllSolutions

我想在这些解决方案中使用 NuGet。问题是如果我在每个解决方案中使用不同版本的同一个 NuGet 包,那么每个解决方案都会覆盖它的前身参考 dll。

我正在考虑一个解决方案,但我不知道这是否可行以及如何实现。

类似:

-Root
--Solution1
--Solution2
--Solution3
--PackagesFolderForAllSolutions // can be done with repositoryPath right?
--OutputForAllProjectsInAllSolutions
---NugetPackageVersion1
---NugetPackageVersion2
---NugetPackageVersion3

有可能吗?这是一个很好的解决方案吗?怎么做? 如果没有,有更好的建议吗?

提前致谢。

  • 编辑:我希望我可以为所有人使用 1 个解决方案,但它是遗留代码,而且过于复杂。

设置是包含多个解决方案的 1 个源代码存储库。

【问题讨论】:

  • 这样组织您的解决方案的原因是什么?为什么不让它们彼此独立!
  • 遗留代码.. :(

标签: c# reference nuget nuget-package project-structure


【解决方案1】:

真正的问题似乎是“我如何确保所有项目都使用相同版本的依赖项”,但我不清楚您是否建议使用共享包文件夹以节省磁盘空间。使用共享文件夹并不能解决多个版本的问题,您最终会得到一个包含多个版本的包的包文件夹,但也许您想节省磁盘空间,所以我将作为一个单独的问题来回答。我将避免固执己见的“这是一个好的解决方案”,但在我看来,您要求的“更好的解决方案”是将所有项目迁移到 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,因为当项目在其存储库根目录之外写入文件时,我讨厌它。

【讨论】:

  • 非常感谢您的详细回答。我提出的建议的主要部分不是全局“包”文件夹(我不关心磁盘空间),而是不同版本的输出文件夹中的相同 dll。假设我在输出文件夹中有两个可执行文件 - 1.exe 和 2.exe,它们使用相同 dll (nuget) 的不同版本 - a.dll。是否可以在输出文件夹中同时拥有两个版本的 a.dll(每个版本都在一个单独的嵌套文件夹中)并让 1.exe 和 2.exe 使用它们各自需要的版本?
猜你喜欢
  • 1970-01-01
  • 2011-11-09
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-01-24
  • 2012-05-17
  • 2018-10-02
相关资源
最近更新 更多