1

在某些主机上，nuget.exe restore solution.sln 在构建之前使用强制包恢复时，我观察到该命令与 Nuget 可视插件相比的行为方式不同。

在某些主机上，命令版本将构建号（默认值 0）附加到版本号，导致包文件夹中的路径包含该构建号。

因此，例如，而不是：

/packages/my_package.1.57.0/...

我有：

/packages/my_package.1.57.0.0/...

最后它会导致构建失败，因为在内部，存储在 .vcxproj 中的目标正在寻找不包含构建号的第一个路径。我不知道它是否与观察到的行为有关，但这些包是使用CoApp构建的本机 C++ 包

如果不是在同一主机上使用 nuget.exe，而是使用 Visual 2013 中的包管理器恢复功能，它运行良好，并且包使用不包含内部版本号的路径正确复制。然后构建就可以了。

由于nuget.exe在某些主机上而不是在其他主机上工作，我怀疑组件的不同版本或不同的默认设置。

对于我检查过的组件：

nuget 版本：2.8.50926.602

视觉 2013 版本：12.0.31101.00 更新 4

它们在工作和不工作的主机上都是相同的。那么还剩下什么？

4

1 回答 1

0

最后它结束了以下简单的场景（不幸的是我无法重现这个问题）：

  • 包在哪里麻烦自制的boost库包。
  • 其中一些包可能以相同的名称提供，但在 nuget.org 上的内容和版本编号不同

在有问题的工作站上，我能够通过以下方式解决它：

  • 从 repos 列表中禁用 nuget.org
  • 最重要的是 => 清除 nuget 缓存！

即使我无法重现：我对这种情况很有信心，因为在查看包内部时，我发现内容与我构建的内容不同。所以这个包是从别处下载的。

于 2015-06-19T12:09:18.967 回答