PackageReference或ProjectReference到同一解決方案中的組件？

Question

讓我們考慮一個場景，在該場景中，我們有兩個.NET Standard項目要公開並為以下項目創建NuGet包：

圖書館解決方案

ClassLibrary1（CL1）

∟ClassLibrary2（CL2）

重要的是要提到CL1與CL2具有ProjectReference。

NuGet的文檔指出，理想情況下，我們應該使用一個程序集生成一個包，因此我們為每個包創建一個NuGet包。

當我們需要在LibrarySolution的范圍內確定CL1中需要哪個版本的CL2時，就會出現問題，因為我們有直接的項目參考。

我想到以下兩種方法：

1. 在解決方案中維護項目引用，這意味着我們需要將程序包版本存儲在csproj文件中，提交版本更改等，以便版本約束和依賴性要求正確（我們目前在CI管道和當前版本中處理版本控制）版本存儲在此處，而不是代碼中）。

2. 將對CL2的依賴關系轉換為PackageReference。 這樣，CL1將始終依賴於已發布的CL2版本。 但是，這樣做將意味着圍繞發布和更新NuGet軟件包（批准PR，合並，CI等）進行所有操作，這可能會非常耗時。

我認為選項1更好，但還是有點手動。 是否有解決此問題的最佳方法？ 我寧願不要使用包來引用位於相同解決方案內部的項目，因為這會導致不必要的間接訪問。

Answer 1

根據我的經驗，使用PackageReference的方法最簡單，頭痛最少。 是的，還有更多的開銷，但這使所有事情都變得明確，這是官方支持的解決方案。

（如果您對這條路線感到猶豫，因為每次更改CL2時都需要更新CL1，也許您需要考慮組件化是否有意義。理想情況下，CL2應該定義相對穩定的接口，並且可以獨立於CL1進行更改。）

否則，有兩種您沒有提到的方法：

3. 在單個NuGet程序包中包含兩個dll。 盡管現有工具尚未正式支持此功能，但此處介紹了幾種解決方法： https : //github.com/NuGet/Home/issues/3891

4. 將這兩個項目合並到一個庫中，因為無論如何它們都像我上面提到的那樣緊密地結合在一起。

Answer 2

首先，您可以使用ProjectReference正確地執行操作。 同一解決方案中的兩個項目甚至沒有理由知道另一個軟件包的存在。 現在，由於您在同一解決方案中擁有CL1和CL2，我想CL1需要CL2的最新版本。

考慮到前一個因素，您只需添加<GeneratePackageOnBuild>true</GeneratePackageOnBuild>標記即可生成構建軟件包，MSBuild會將其更改為NuGet依賴項，使其與軟件包中的最新版本相關。