NuGet依赖地狱

Question

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

目前我们问自己这是否是一个很好的解决方案： 我们的主要项目是使用依赖注入来解决依赖关系。 因此，我们有一个项目结构，如：

• 接口（.dll）
• DataLayer（.dll）
• 本地化（.dll）
• 基础设施（.dll）
• 应用程序（.exe）

在我看来，我想把这些东西分成更小，更小的解决方案，以保持简单易用：

• 接口（只有一个项目：接口定义）
• 组件（三个项目：使用DataLayer，本地化和基础架构）
• 应用程序（只有一个项目：只有exe）

这引出了一个问题，即如果有人正在更改接口，我们必须更新每个组件项目中的接口的nuget-packet-version，提交对我们的构建系统的更改，然后更新应用程序本身。它有点像DLL Hell - 另外调试和开发有点难，如果你试试，因为几个项目是分开的。

这个结构是否废话？在您看来，什么是解决依赖关系以及减少和解开大型解决方案的好方法？或者您会建议将所有项目合并为一个大型解决方案吗？

Answer 1

您推荐的方法＆＃34;如果有人正在更改接口，我们必须更新每个组件项目中的接口的nuget-packet-version，将更改提交到我们的构建系统＆＃34;实际上并不是最好的做法，在你扩展时会引起问题。

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

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

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

流程我建议 -

1. 将每个包的开发与其消费者分开。这种方法可以很好地扩展，并为消费者提供OPT-IN选项以进行新的更改。
2. 创建一些系统/约定，其中包的开发人员可以让消费者知道何时发布新版本。正确的发行说明/简单的博客也足够了。
3. 使用新软件包的应用程序/项目的开发人员只有在包含消费者需要的功能时才会使用最新版本