NuGet與packages.config，項目引用和solutionwide packages文件夾有關

Question

我們開始使用NuGet，我們遇到了一些問題：

首先是一些NuGet事實：

（只是為了確保我們了解NuGet的工作原理）

• 在添加，更新或刪除包時，會創建並更新packages.config（位於project-root中）。 在此文件中，包版本屬性反映了正在使用的完整版本，因此從這個意義上說它也是一個狀態。 可以將allowedVersions屬性添加到包規范中，這是對可以更新的版本的限制。 要使程序包還原起作用，此文件需要受源代碼管理。

• packages文件夾位於solution-root中，並在子文件夾中包含一個下載版本的依賴包，其名稱與包名稱（包括版本）相匹配，以允許多個中的不同項目使用同一個包的多個版本 - 項目解決方案。 建議不要將它們作為二進制文件來源控制，並且包恢復可以在需要時重新創建它們。 更新包時，將使用其中的包創建與更新匹配的新文件夾。

• 項目文件包含對packages文件夾中的包的引用，以使構建工作，並且visual studio也能夠提供自動完成，智能感知等。 更新包時，項目文件中的引用將更新以匹配packages文件夾中包的新位置。

問題：

1. 由於packages.config文件包條目包含完整的版本信息，因此我們經常需要更新源控件存儲庫。 或者，我們可以在大多數情況下忽略這些更改，但是當版本發生變化時，我們（在大多數情況下）會忽略它們。 這似乎是非常不必要的，因為NuGet恢復應該能夠知道允許哪些版本（通過allowedVersions）。

2. 必須手動添加allowedVersions屬性，這很容易被遺忘。 我們正在使用語義版本控制，因此對於我們來說，在安裝即Foo-1.1.0版本時，應隱含allowedVersions =“[1,2]”。

3. 當添加allowedVersion時，NuGet包恢復似乎無法找到-prerelease程序集（可能是一個錯誤？）。

4. 為什么NuGet在解決方案級別處理包？ 如果您正在使用包含項目A（repo-1）和項目B（repo-2）的混合搭配解決方案，那么解決方案級別的打包將無法正常運行。 也就是說，如果您將該解決方案文件保存在一個單獨的位置，那么事情可能仍然有效。 但是，如果你然后設置另一個包含項目-A（repo-1）和項目-C（repo-3）的解決方案，那么項目-A將突然再次需要一個包恢復，更糟糕的是，項目引用將是更改為匹配上次更改。 回到第一個解決方案將有參考不起作用。 檢查這些肯定會使它們不適合其他人。

5. 在程序包更新中，更新項目文件引用（以匹配其中包含versionid的新foldernames），並將顯示為未提交的更改。 承諾這一變化似乎是常態，但我們認為這不是必要的。

關於ExcludeVersion的注釋 （可以建議作為上述問題的解決方案：

• 您只能在手動執行NuGet命令時提供該選項。 通過Visual Studio中的NuGet菜單安裝/更新軟件包時，無法使用該選項。 使用任何自動化工具意味着必須手動修復foldername和項目引用。

• 我們知道ExcludeVersion不是默認設置，可能是因為支持某人在多項目解決方案中工作的情況，其中不同的項目依賴於同一個包的不同版本。

可能的解決方案？

（但是，這可能需要NuGet生態系統的重大變化？）

A - packages.config

我希望packages.config中的每個package元素都可以拋棄allowedVersions，而是將version更改為范圍說明符。 packages元素還應提供一種單獨標識從哪個源獲取更新的方法。 最后，如果已安裝的軟件包遵循語義版本控制，則版本屬性應根據安裝的版本自動設置版本范圍。

示例packages.config：

`<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Foo" version="[1,2] source="Development Feed">
</packages>`

這個會：

• 修復了package.config文件過多提交的問題，因為版本屬性不再經常更新。

• 無需記住為語義版本的項目設置范圍。

• 確保從所需的源中獲取包，並且通過在錯誤的源中查找它而不浪費時間。

B - Packages文件夾和其中已安裝軟件包的名稱

我希望packages文件夾位於每個項目根目錄中，並且子文件夾名稱僅限於包名稱，不包括版本。 這個會：

• 修復了項目文件過多提交的問題，因為項目文件中的項目引用現在指向更新后的同一個包文件夾。

• 允許項目使用相同包的不同版本，因為它們真正相互獨立。

---

我們很高興聽到所列問題的解決方案。

Answer 1

正如NuGet Enterprise中所建議的那樣- 針對不同成熟度級別的包的最佳實踐 ，我認為你做的事情比必要的更復雜:)

1. 為什么你不想捕獲編譯代碼的包的版本？ 這是可靠診斷和可重復構建的關鍵信息。 鑒於您可能會將代碼更改提交回版本控制，提交有關使用哪些包來幫助構建該源的詳細信息非常有用。
2. “ 當安裝即Foo-1.1.0版本時，allowedVersions =”[1,2]“應該暗示 ”我不認為允許版本真的可以被暗示，因為並非所有NuGet包都堅持SemVer（參見崩潰log4net 1.2.11 ）。 設置一個grep for allowedVersions作為CI構建或預提交/ pre-push Dev檢查的一部分應該抓住這個。 它不應該經常改變，並且注意它是有用的（如果其他團隊和包正確地使用SemVer，無論如何:)）。
3. 要查找Prerelease包，您需要在nuget安裝上使用Prerelease或-IncludePrerelease標志。
4. “ 如果您正在使用混合匹配解決方案，其中包含項目-A（repo-1）和項目-B（repo-2） ” - 為什么要安排這樣的代碼？ 單個解決方案的代碼應該存在於同一個repo中。 在回購中破解解決方案代碼肯定會很痛苦！
5. 您可以告訴nuget使用無版本文件夾名稱來安裝包（ -ExcludeVersion ）。

我強烈建議使用命令行nuget.exe和構建腳本來放棄Visual Studio NuGet集成。 這尤其涉及＃5，但通常與NuGet的交互。 當單獨使用nuget.org feed中的第三方公共包時，Visual Studio集成很好，但在處理內部NuGet提要和包時，它不夠靈活。