問題：
我有一個由許多包組成的工具包，源代碼只是一個包含包源、單元測驗和演示的大型解決方案。
每個包專案都需要是一個單獨的 NuGet 包，但有些專案依賴于其他專案。
在專案中，我有本地專案依賴項，指向專案檔案。
可以說我有一個根包A。B, C, 并且D取決于A。假設E取決于B.
假設依賴樹如下所示：
- A
|-B-E
|-C
|-D
當我發布包A, B, C, D,時會發生什么E？
包會E只是專案E編譯的依賴包 B（其中B取決于封裝 A） -或包裝E就沒有依賴關系，并A和B 專案建成？
請注意專案參考和包參考之間的區別！
在我的解決方案中，我只有專案參考。我在生成的包中想要的是包參考。我B.csproj應該依賴，A.csproj但我B.nupkg應該依賴A.nupkg。
我想要實作的是能夠在不破壞其余包的情況下升級單個包。當然，我指的是非破壞性更改，例如向 A 添加類或方法，在不更改 API 的情況下修復 A 中的錯誤。
假設我在包中發現了一個A影響所有其他包的錯誤。我只想修復軟體包A并將其作為新版本發布。然后，X使用包的專案B也應該收到修復，因為它將使用最新版本的A依賴項。
是否有可能，我應該怎么做才能實作這種行為？
我測驗了幾種（某種）有效的方法。首先，我只是首先發布了依賴項，然后將 NuGet 包依賴項添加到使用它們的專案中。我的意思是后來作為包發布的專案。這行得通，但是除錯起來非常乏味。實際上是一種噩夢。
然后我測驗了另一種方法 - 兩種參考在Debug和Release配置之間變化。該Debug配置必須在專案的參考檔案，其Release配置得軟體包的參考。這實際上非常易于管理，但是，專案檔案非常混亂，這一切都非常復雜并且維護起來仍然很乏味。
我在某處讀過，.NET 和 NuGet 會以某種方式自行解決。我覺得很難相信。有那么聰明嗎？只需保留正常配置，對專案的參考，如果可用，包將參考相應的包嗎？
有人可以確認或否認嗎？
有一種方法可以找出并發布包。但它并不是完全可逆的。用于 NuGet 的內容將永遠留在那里。我可以取消列出這些版本，但測驗它仍然需要很多時間，而且會造成混亂。
也許有人已經對此進行了測驗，或者找到了一些關于它的可靠資訊。
uj5u.com熱心網友回復：
我在某處讀過，.NET 和 NuGet 會以某種方式自行解決。我覺得很難相信。有那么聰明嗎？只需保留正常配置，對專案的參考，如果可用，包將參考相應的包嗎？
打包專案時，NuGet 會將 ProjectReferences 轉換為包依賴項，就像 PackageReferences 成為包依賴項一樣。沒有什么聰明的，事實上它非常簡單。因此，無需根據除錯與發布或其他任何內容進行切換。驗證自己非常容易：
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
命令列上的這些命令將創建 MyLib1.1.0.0.nupkg 和 MyLib2.1.0.0.nupkg，然后您可以以任何您喜歡的方式檢查這些 nupkg（Visual Studio 的包管理器 UI、NuGet 包資源管理器，只需打開 nuspec檔案）并看到 MyLib1 依賴于 MyLib2 版本 1.0.0。在打包時，NuGet 查看專案參考，確定打包后 MyLib2 的包版本，然后將其用作 MyLib1 中的依賴項版本。
基本上在簡單的情況下，你的類別庫只不過是一個程式集（一堆.cs被編譯的檔案），你真的不需要考慮 NuGet，它只是以你期望的最天真的方式作業到。
由于打包創建的專案的解決方案都使用 ProjectReferences，因此除錯或開發并不繁瑣，因為在您完成除錯和開發并準備發布之前，NuGet 甚至不會發揮作用。
有一種方法可以找出并發布包。但它并不是完全可逆的。用于 NuGet 的內容將永遠留在那里。
只有 nuget.org，但沒有理由必須為您的包使用 nuget.org。事實上，創建專有軟體的公司不可能將其內部包發布到 nuget.org。但是 NuGet 允許您配置多個源，如果您愿意，甚至可以洗掉 nuget.org。有類似dotnet nuget add source ...or 的命令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 }。然后創建一個新的解決方案，您要在其中測驗包
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 假定所有包 id-version 都是全域唯一且不可變的。這意味著如果您嘗試測驗您的包，找到一個錯誤，修復錯誤，然后嘗試在不更改包版本的情況下進行測驗，NuGet 將在您的全域包檔案夾中看到該包并使用該舊副本，因此您不會看到你的修復。這就是為什么最好不要使用 PackageReference 進行測驗，而只需使用 ProjectReference。但是無論如何，如果您遇到這種情況，請自己從全域包檔案夾中洗掉該包，或者您可以使用dotnet nuget locals global-packages --clear，這將清除所有包，而不僅僅是您正在測驗的包。定向洗掉的需求并不大。
另一種選擇是globalPackagesFolder在測驗解決方案的 nuget.config 中設定設定。遺憾的是nuget.exe config還沒有移植到 dotnet CLI，所以要么從 nuget.org/downloads 下載 nuget.exe，要么直接編輯 nuget.exe 將檔案夾設定到其他位置，這樣不會影響你的正常開發當你dotnet nuget locals global-packages --clear在你的包測驗解決方案中。
此檔案頁面還列出了托管您自己的私人提要的多個選項，盡管本地檔案夾最容易除錯。許多公司使用網路檔案共享而不是服務器，但請注意，由于 nuget 無法索引本地檔案夾或網路共享上的包元資料，因此使用 Visual Studio 的包管理器 UI 將比托管 HTTP 提要（確實有搜索索引），如果檔案夾包含許多 nupkg 時恢復速度也較慢，我不會感到驚訝。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/406515.html
標籤：