大型解决方案中的内部NuGet包管理

Question

当我们开始我们的最新项目(大型框架)时,我们开始使用ProGet作为我们的包服务器和TeamCity进行构建(Visual Studio Team Services是SC).该框架中的一个解决方案包含近60个代码库,它们实现了从redis到外部API和常见模型的包装器的所有功能.这些库中的每一个都是一个nuget包.在项目的早期,很容易在核心库中进行更改,检查它,TeamCity将构建并推送到proget并快速更新,并且您已经关闭并运行.

虽然这变得无法管理,但团队决定在开发过程中,公共库解决方案中的nuget包不会通过其包引用彼此,而是直接引用.这当然加快了开发速度,但对消费应用程序产生了令人讨厌的副作用.虽然公共库是直接引用,但是在更新任何内部包时,微服务框架的7个主要部分(web api,多个mvc和一些工作者角色)将获得相同核心库的多个副本,而所有其他库依赖于这些库.上.

例如,有一个名为"core"的lib,它具有构建块,几乎所有内容都是在公共库中构建的.它有很多接口等等......好吧,因为所有其他的lib都直接使用它们,它们都直接在它们的输出中获得了一个核心副本,更令人担忧的是我们的teamcity服务器为我们处理版本控制,所以它们不仅仅是每个都有一个核心副本,但其版本与使用它的nuget包的版本相匹配.

虽然不是很好,但这仍然不是问题的症结所在.在消费应用程序中进行nuget更新期间,应用程序中的每个库可能会引用不同版本的核心,具体取决于更新的程序包的顺序,这些程序偶尔会导致构建错误并搜索恶意引用.

既然项目正在进入最后阶段,我想永久解决这个问题,但我不确定如何.

为了让nuget包作为nuget包相互消耗,单个更新可能需要几个小时,因为一个依赖包被更新,你重建,它会生成另一个nuget包,链中更高的包需要等等...

然而,版本控制至关重要,因为在引入重大更改时,我们希望利用nuget依赖关系来防止在需要时进行升级.

有没有其他人遇到这个并解决了它？如果nuget被任何开发团队完全接受并且生成一个相当大的项目,那么这似乎是相当普遍的.

更新:

引擎盖下发生的事情的例子.

CoreLib(接口等)Lib1(直接引用Corelib,当前版本= v1.0.17)Lib2(直接引用Corelib,当前版本= v1.0.99)

Lib1和Lib2都是nuget包.对Lib1进行了更新,其中包括对CoreLib的不间断更改.签入Lib1时,TeamCity启动构建并创建新的nuget包,v1.0.18).

当Lib1的软件包在消费项目中更新时,Lib1的CoreLib副本(也是v1.0.18,因为AssemblyVersion由TeamCity管理)的版本低于Lib2的版本(v1.0.99),即使它是落后的版本.

最终目标是让所有这些相互依赖的软件包自行重建,更新和重新打包,但如何自动执行此操作实际上是在逃避我.

Answer 1

单个解决方案中的项目引用优于创建和发布中间 nuget 包并使用它们。

当您拥有多个解决方案时，Nuget 包是管理“中间”工件版本控制的一种极好方法。由于多种原因，您可能会拥有多个解决方案，但一个常见的原因是您拥有多个开发团队。

假设您设置了内部 nuget 服务器。Visual Studio 解决方案不允许您有循环引用，编译器会选择它。因此，您需要仔细管理 nuspec 文件中的所有依赖项，以查找解决方案中项目引用未涵盖的依赖项。

有关 nuget 包版本控制语法的有用参考请参见此处。