NuGet依賴地獄

Question

我有一個小問題，關於自己的NuGet服務器和我們推動它的NuGet包。 我們有幾個項目和一個改編的TFS構建過程，它將NuGet包自動推送到我們的NuGet服務器 - 到目前爲止它工作得很好。

目前我們問自己，如果這是一個很好的解決方案： 我們的主要項目是使用依賴注入來解決依賴關係。 因此，我們有一個項目的結構，如：

• 接口文件（.dll）
• 數據層（.dll文件）
• 本地化文件（.dll）
• 基礎設施文件（.dll）
• 應用（。 exe）

在我看來，我想分解成更多，更小的解決方案，以保持事情簡單易用：

• 接口（只有一個項目：該接口定義）
• Compontents（三個項目：與數據層，本地化和基礎設施）
• 應用（只有一個項目：只有EXE）

這導致我們的問題是，如果有人正在改變接口，我們將不得不在每個組件項目中更新接口的nuget-packet-version版本，將更改提交到我們的構建系統，然後更新應用程序本身。這有點像DLL Hell - 除此之外，如果你嘗試一下，因爲有幾個獨立的項目，調試和開發有點難。

這個結構是否廢話？你認爲什麼是解決依賴關係並將大型解決方案縮小並解包爲小型解決方案的好選擇？或者你會推薦將所有項目整合到一個大型解決方案中？

Answer 1

您推薦的方法「如果有人正在更改接口，我們將不得不更新每個組件項目中的接口的nuget-packet-version，將更改提交給我們的構建系統」實際上不是最佳做法，並且會隨着規模的擴大而出現問題

理想情況下，您希望將開發包與開發消費者分開。考慮你的組件包和應用程序層。如果當前設置的應用程序項目正在使用組件包的1.0.0.0。有人前往並添加一個新組件到組件包並創建一個版本1.1.0.0。現在，如果你去和更新組件包的應用程序項目，下面的事情會發生包含在套餐獲取帶來了新的組件

1. 任何bug修復（這可能是一件好事）
2. 任何新的組件添加到程序包中的應用程序項目（只有當應用程序要使用新組件時纔是好事，否則它根本不會影響應用程序）
3. 任何在進程中添加的新bug創建可能會無意中影響現有組件功能的新組件也會被拉進來。

在我看來，第3點是軟件包更新的最危險的影響。每當我知道該軟件包的更新版本將會修復一個錯誤或引入應用程序中需要的新功能時，我可以冒險增加新的錯誤。然而，如果我不打算使用新的組件，我基本上會在應用程序項目中引入不穩定性，因爲沒有額外的優勢。

方法I將中推薦使用

1. 分隔每個包的發展從其消費者。這種方法可以很好地擴展，並讓消費者可以選擇OPT-IN進行新的更改。
2. 創建一些系統/約定，其中包的開發者可以讓消費者知道何時發佈新版本。正確的發行說明/簡單的博客也足夠了。
3. 只有在包含消費者需要的功能時，才允許使用新軟件包的應用程序/項目的開發人員才能使用最新版本