在Visual Studio 2015解决方案中恢复所有Nuget包

Question

我已经阅读了许多SO和NuGet (以及互联网上的其他内容)，但我似乎无法解决我在Visual Studio 2015中使用NuGet包恢复时遇到的问题。 我有以下情况。

解决方案A结构

- Project A

如果我打开并构建Solution A，我会看到显示nuget包恢复进度的对话框，并且解决方案成功构建。

解决方案B结构

- Project A - Project B

但是，假设我从TFS进行了新的拉取并且没有构建过Solution A，则如果我打开并构建Solution B，我会看到显示nuget包恢复进度的对话框，但构建失败，因为Project A无法构建。

似乎正在发生的事情是NuGet正在为Project B还原软件包，但不适用于Project A，因此构建失败。 重点是，如果我查看Project B的引用，所有NuGet引用均已解析，但Project A的引用仍然存在问题。

一些要点：

- 我已禁用了NuGet的源代码控制集成，因此不会检查Packages文件夹。 - 每个项目都有自己的packages.config文件 - Solution B的构建顺序为Project A，然后是Project B

非常感谢您的想法。

- dparsons

---

你能展示一下你的.csproj文件和packages.config文件中相关的文本吗？ - Matt Rowland

是的，我们遇到了同样的问题，好像是project.json文件混乱了。我们尝试了各种方法，添加在解决方案层，只在项目层添加等等。似乎只要一个项目参与多个解决方案，Nuget就会出问题。事实上，即使引用部分明显显示黄色指示器，它也会告诉你已经安装了这些内容。在过去的6个月里，Nuget变得一团糟...你能做的几乎只有在必要时重新安装，只需点击管理Nuget卸载，然后在线查找包并重新安装。 - JWP

我已将您的答案从问题中分离出来，因为问题不应该包含答案。我添加了一个[维基答案]（https://dev59.com/NZjga4cB1Zd3GeqPK37q#45106397），其中包含详细信息。如果您想自己添加答案，请告诉我，我会删除维基页面。 - Liam

Answer 1

默认情况下，NuGet在解决方案根目录中创建解决方案的“packages”文件夹，并且每个项目都将其软件包DLL引用到该“本地”软件包文件夹。在您的示例中，如果您打开Project A的.csproj文件，您可能会看到引用路径类似于“..\ packages \ [package name] \ [etc]”。

因此，当您从TFS进行新的拉取并构建Solution B时，Project A找不到其DLL，因为“c：\ workspace \ Solution A \ packages”尚不存在（或者在您的计算机上的绝对路径是什么）。

要更正此问题，请使用共享软件包文件夹，在处创建它。要执行此操作，您必须在每个解决方案的NuGet.config中添加一个附加节点（有关详细信息，请参见https://docs.nuget.org/consume/nuget-config-file;我还假设您在处拥有一个NuGet文件夹）。

<config>
  <add key="repositorypath" value="..\..\packages" />
</config>

我在这里使用了相对路径，但是您也可以使用绝对路径，文档还说您可以使用 %HOME%。

这样做后，请重新启动 Visual Studio。下次打开包管理器时，它应该会询问您是否要恢复缺失的包，并假设您选择是，它将把它们放在新位置。最后一步是编辑 .csproj 文件并将所有实例的 ..\packages 更改为 ..\..\packages（或者您可以卸载和重新安装包，但我发现编辑 .csproj 更快）。

- howcheng

---

谢谢！这解决了我在本地拉取解决方案时的问题，但是现在当我在构建服务器上进行构建时，只有解决方案A的包被恢复，而解决方案B失败了。如果我登录到构建服务器并在Visual Studio中打开解决方案B并手动构建，包会成功恢复并且构建成功。我的构建定义中的构建顺序是解决方案A -> 解决方案B。有什么想法吗？ - dparsons

不必理会。我已经解决了这个问题，并在我的原始问题中更新了完整的解决方案。 - dparsons

Answer 2

恢复 Nuget 包需要执行以下步骤：

• 在项目属性中更改目标框架
• 清理项目
• 设置先前的目标框架
• 重新生成项目

希望这可以帮到您。

- B.Kosmowski

---

在我的情况下它是有效的。我希望他们会在VS2017中解决这个问题。 - B.Kosmowski

Answer 3

_{摘自OP的问题}

howcheng的答案基本上是正确的，但有一些注意事项。在实施howcheng建议的更改后，我能够使用一个中央“packages”文件夹在本地构建所有解决方案，而不管解决方案如何。然而，我遇到的问题是，当我将这些更改检入TFS时，我的CI构建启动并失败了！

我的CI Build Definition使用默认的XAML过程模板构建Solution A和Solution B，而不是.proj文件。我看到的错误似乎表明Solution A正在恢复其包，但Solution B没有。如果我登录到构建服务器并在VS 2015中打开Solution B，一切都正常；经过几个小时的谷歌搜索，我找到了this文章，最终导致我找到了答案。

我正在使用Visual Studio 2015进行开发，但是我正在使用TFS 2013进行源代码控制和构建。尽管我已经在构建服务器上安装了Visual Studio 2015，但MSBuild仍然引用了随TFS 2013一起发布的NuGet版本，而不是VS 2015中包含的版本。一旦我从TFS工具目录运行了nuget update -self，我的构建就正常工作了。

- Liam