当我们开始进行最新项目（大型框架）时，我们使用ProGet作为我们的软件包服务器，使用TeamCity进行构建（Visual Studio Team Services是SC）。框架中的一个解决方案包含将近60个库，实现从redis到外部API的包装器和常见模型的所有代码。每个这些库都是一个nuget软件包。在项目早期，非常容易更改核心库中的内容，检查它，然后由TeamCity构建并推送到ProGet，稍加更新就可以运行。
但是不久后，这变得难以管理，团队决定，在开发过程中，常用库解决方案中的任何nuget软件包都不会通过其软件包互相引用，而是直接引用。当然，这加快了开发速度，但对使用应用程序产生了负面影响。虽然常用库直接引用，但微服务框架的7个主要部分（Web API、多个MVC和一些工作角色）在更新任何内部软件包时，都会获得同一核心库的多个副本，而其他所有库都依赖于该库。
例如，有一个名为“core”的单个库，其中包含几乎所有通用库构建块的构建方式。它有许多接口等。由于所有其他库都直接使用它，它们都直接在其输出中获得了core的副本，更令人担忧的是，我们的TeamCity服务器为我们处理版本控制，因此它们每个都有core的副本，并且其版本与使用它的nuget软件包相匹配。
虽然这并不是最大的问题，但在使用应用程序中进行nuget更新时，应用程序中的每个库可能引用core的不同版本，具体取决于更新软件包的顺序，这偶尔会导致构建错误和寻找“流氓”引用。
现在项目正在进入最终阶段，我想永久地解决这个问题，但我不确定如何解决。
要让nuget软件包作为互相的nuget软件包来消费，单个更新可能需要几个小时，因为一个依赖软件包被更新，你需要重新构建，它产生另一个nuget软件包，而链条上更高级别的软件包需要它等等。
但是不久后，这变得难以管理，团队决定，在开发过程中，常用库解决方案中的任何nuget软件包都不会通过其软件包互相引用，而是直接引用。当然，这加快了开发速度，但对使用应用程序产生了负面影响。虽然常用库直接引用，但微服务框架的7个主要部分（Web API、多个MVC和一些工作角色）在更新任何内部软件包时，都会获得同一核心库的多个副本，而其他所有库都依赖于该库。
例如，有一个名为“core”的单个库，其中包含几乎所有通用库构建块的构建方式。它有许多接口等。由于所有其他库都直接使用它，它们都直接在其输出中获得了core的副本，更令人担忧的是，我们的TeamCity服务器为我们处理版本控制，因此它们每个都有core的副本，并且其版本与使用它的nuget软件包相匹配。
虽然这并不是最大的问题，但在使用应用程序中进行nuget更新时，应用程序中的每个库可能引用core的不同版本，具体取决于更新软件包的顺序，这偶尔会导致构建错误和寻找“流氓”引用。
现在项目正在进入最终阶段，我想永久地解决这个问题，但我不确定如何解决。
要让nuget软件包作为互相的nuget软件包来消费，单个更新可能需要几个小时，因为一个依赖软件包被更新，你需要重新构建，它产生另一个nuget软件包，而链条上更高级别的软件包需要它等等。
版本控制对于IT技术开发至关重要，因为当引入破坏性更改时，我们希望利用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副本（因为AssemblyVersion由TeamCity管理，所以也是v1.0.18）低于Lib2的版本（v1.0.99），即使它滞后一个版本。
最终目标是使所有这些相互依赖的软件包重新构建、更新和打包自己，但如何自动地完成这些步骤目前还不太清楚。