dependencies - NuGet 依赖 hell

Question

我有一个关于自己的 NuGet 服务器和我们正在推送给它的 NuGet 包的小问题。我们有几个项目和一个经过调整的 TFS 构建过程，它自动将 NuGet 包推送到我们的 NuGet 服务器 - 到目前为止它运行良好。

目前我们在问自己这是否是一个好的解决方案:我们的主要项目是使用依赖注入(inject)来解决依赖关系。因此我们的项目结构如下:

• 接口(interface)(.dll)
• 数据层(.dll)
• 本地化 (.dll)
• 基础架构 (.dll)
• 应用程序(.exe)

在我看来，我想将事情拆分成更多、更小的解决方案，以保持事情简单易用:

• 接口(interface)(只有一个项目:接口(interface)定义)
• 组件(三个项目:DataLayer、本地化和基础架构)
• 应用程序(只有一个项目:只有exe)

这导致我们遇到一个问题，如果有人正在更改接口(interface)，我们将不得不更新每个组件项目中接口(interface)的 nuget-packet-version，将更改提交到我们的构建系统，然后更新应用程序本身。它有点像 DLL hell - 此外，如果您尝试这样做，调试和开发会有点困难，因为多个项目是分开的。

这个结构是废话吗？在您看来，解决依赖关系以及将大型解决方案缩减和解包为较小解决方案的好选择是什么？或者您会建议将所有项目整合到一个大型解决方案中吗？

Answer 1

您推荐的方法“如果有人正在更改接口(interface)，我们将不得不更新每个组件项目中接口(interface)的 nuget-packet-version，将更改提交到我们的构建系统”实际上不是最佳实践，并且会导致随着规模的扩大而出现问题。

理想情况下，您希望将包的开发与消费者的开发分开。考虑你的组件包和应用层。如果您当前的设置是应用程序项目正在使用您的组件包的 1.0.0.0。有人进去并向组件包添加一个新组件并创建一个版本 1.1.0.0。现在，如果你进入并更新 Application 项目中的 Components 包，将会发生以下事情

1. 新组件包中包含的任何错误修复都被引入(这可能是件好事)
2. 任何添加到包中的新组件都将可供应用程序项目使用(只有当应用程序要使用新组件时这是一件好事，否则它根本不会影响应用程序)
3. 在创建新组件的过程中添加的任何可能无意中影响现有组件功能的新错误也会被纳入。

在我看来，第 3 点是包更新最危险的影响。每当我知道更新版本的包将修复错误或引入我在应用程序中需要的新功能时，我可以冒添加新错误的风险。但是，如果我不打算使用新组件，我基本上会在应用程序项目中引入不稳定性，而没有任何额外的优势。

我会推荐的过程-

1. 将每个包的开发与其使用者分开。这种方法可以很好地扩展，并为消费者提供了选择接受新变化的选项。
2. 创建一些系统/约定，使包的开发人员可以在发布新版本时让消费者知道。适当的发行说明/一个简单的博客也足够了。
3. 让使用新包的应用程序/项目的开发人员仅在最新版本包含消费者所需的功能时才引入最新版本