考慮到它們之間的依賴關系，我應該如何將我的項目發布為 NuGet 包？

Question

問題：

我有一個由許多包組成的工具包，源代碼只是一個包含 package 源代碼、單元測試和演示的大型解決方案。

每個 package 項目需要是一個單獨的 NuGet package，但有些項目依賴於其他項目。

在項目中，我有本地項目依賴項，指向項目文件。

假設我有一個根 package A 。 B ， C ， D取決於A 。 假設E取決於B 。

假設依賴樹如下所示：

- A
  |-B-E
  |-C
  |-D

當我發布包A 、 B 、 C 、 D 、 E時會發生什么？

package E是否只是項目E編譯時依賴於包B （其中B取決於package A ） - 還是B E中A和項目沒有依賴關系？

請注意項目參考和package 參考之間的區別！

在我的解決方案中，我只有項目引用。 我在生成的包中想要的是 package 參考。 我的B.csproj應該依賴於A.csproj但我的B.nupkg應該依賴於A.nupkg 。

我想要實現的是能夠在不破壞 rest 的情況下升級單個軟件包。 當然，我的意思是非破壞性更改，例如向 A 添加 class 或方法，在不更改 API 的情況下修復 A 中的錯誤。

假設我在 package A中發現了一個影響所有其他軟件包的錯誤。 我只想修復 package A並將其作為新版本發布。 然后，使用 package B的項目X也應該收到修復，因為它將使用最新版本的A依賴項。

是否有可能，我應該怎么做才能實現這種行為？

我測試了幾種（某種）有效的方法。 首先，我剛剛發布了依賴項，然后將 NuGet package 依賴項添加到使用它們的項目中。 我的意思是后來作為包發布的項目。 這行得通，但是調試起來非常乏味。 實際上是一種噩夢。

然后我測試了另一種方法—— Debug和Release配置之間有兩種不同的參考。 Debug配置引用了項目， Release配置引用了包。 這實際上非常易於管理，但是，項目文件非常混亂，這一切都非常復雜並且維護起來仍然很乏味。

我在某處讀過，.NET 和 NuGet 會以某種方式自行解決。 我覺得很難相信。 有那么聰明嗎？ 只需保留正常配置，對項目的引用，如果可用，包將引用相應的包嗎？

有人可以確認或否認嗎？

有一種方法可以找出並發布包。 但它並不是完全可逆的。 NuGet 的內容將永遠存在。 我可以取消列出這些版本，但測試它仍然需要很多時間，而且會造成混亂。

也許有人已經對此進行了測試，或者找到了一些關於它的可靠信息。

Answer 1

我在某處讀過，.NET 和 NuGet 會以某種方式自行解決。 我覺得很難相信。 有那么聰明嗎？ 只需保留正常配置，對項目的引用，如果可用，包將引用相應的包嗎？

打包項目時，NuGet 會將 ProjectReferences 轉換為 package 依賴項，就像 PackageReferences 成為 package 依賴項一樣。 沒有什么聰明的，事實上它非常簡單。 因此，無需根據調試與發布或其他任何內容進行切換。 驗證自己非常容易：

dotnet new sln
dotnet new classlib -n MyLib1
dotnet sln add MyLib1
dotnet new classlib -n MyLib2
dotnet sln add MyLib2
dotnet add MyLib1\MyLib1.csproj reference MyLib2\MyLib2.csproj
dotnet pack

These commands on a command line will create MyLib1.1.0.0.nupkg and MyLib2.1.0.0.nupkg, and then you can inspect these nupkgs any way you prefer (Visual Studio's Package Manager UI, NuGet Package Explorer, just open the nuspec文件）並看到 MyLib1 依賴於 MyLib2 版本 1.0.0。 打包時，NuGet 查看項目參考，確定打包后 MyLib2 的 package 版本，然后將其用作 MyLib1 中的依賴項版本。

基本上在簡單的情況下，你有 class 庫，它只不過是一個程序集（一堆編譯的.cs文件），你真的不需要考慮 NuGet，它只是以你最幼稚的方式工作期待它。

由於打包創建的項目的解決方案都使用 ProjectReferences，因此調試或開發並不繁瑣，因為 NuGet 甚至在您完成調試和開發並准備發布之前都不會發揮作用。

有一種方法可以找出並發布包。 但它並不是完全可逆的。 NuGet 的內容將永遠存在。

只有 nuget.org，但沒有理由為您的包使用 nuget.org。 事實上，創建專有軟件的公司不可能將其內部軟件包發布到 nuget.org。 但是 NuGet 允許您配置多個源，如果您願意，甚至可以刪除 nuget.org。 有類似dotnet nuget add source...或dotnet nuget remove source...類的命令。 您還可以使用dotnet new nugetconfig引導一個新的 nuget.config 文件，然后使用任何文本編輯器直接編輯 xml。 語法相當簡單，所有文檔都記錄在 docs.microsoft.com/nuget 上。

無論如何，以我之前的示例為例，在創建 MyLib1 和 MyLib2 包后，將它們復制到計算機上的某個文件夾Get-ChildItem -recurse -filter *.nupkg | ForEach-Object { Copy-Item $_ c:\path\to\nupkgFolder } Get-ChildItem -recurse -filter *.nupkg | ForEach-Object { Copy-Item $_ c:\path\to\nupkgFolder } 。 然后創建一個新的解決方案，您要在其中測試包

dotnet new sln
dotnet new nugetconfig
dotnet nuget add source c:\path\to\nupkgFolder -n LocalNupkgs
dotnet new console -n MyApp
cd MyApp
dotnet add package MyLib1

現在，一個問題是 NuGet 假設所有 package id-version 都是全局唯一且不可變的。 This means if you try to test your package, find a bug, fix the bug, then try to test without changing the package version, NuGet will see the package in your global packages folder and use that old copy, so you won't see你的修復。 這就是為什么最好不要使用 PackageReference 進行測試，而只需使用 ProjectReference。 但是無論如何，如果您遇到這種情況，請自己從全局包文件夾中刪除 package ，或者您可以使用dotnet nuget locals global-packages --clear ，這將清除所有包，而不僅僅是您正在測試的包. 定向刪除的需求並不大。

另一種選擇是在測試解決方案的 nuget.config 中設置globalPackagesFolder設置。 Unfortunately nuget.exe config hasn't been ported to the dotnet CLI yet, so either download nuget.exe from nuget.org/downloads, or just hand edit nuget.exe to set the folder to some other location, so it won't當您在 package 測試解決方案中使用dotnet nuget locals global-packages --clear時會影響您的正常開發。

此文檔頁面還列出了托管您自己的私人提要的多個選項，盡管本地文件夾最容易調試。 Many companies use a network file share instead of a server, but be aware that since nuget can't index package metadata on local folders or network shares, using Visual Studio's Package Manager UI will be slower than hosting an HTTP feed (that does have a搜索索引），如果文件夾包含許多 nupkg 時恢復速度也較慢，我不會感到驚訝。