大型解决方案中的内部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包版本的语法的有用的参考是这里 。