5

我们是 NuGet 的热心用户，无论是内部构建的还是第三方包的。

我们最近开始在我们的一些构建项目中启用 NuGet 包还原选项，以减少我们提交给源代码控制的二进制文件的数量，但我们遇到了一个问题。

我们看到 Visual Studio 需要很长时间才能启动，一旦启动（可能需要半个多小时），随后的构建同样耗时。发生这种情况时，您可以在进程资源管理器中看到许多子 NuGet 进程出现和死亡。

我们发现，如果 packages.config 文件中引用的包版本不能从任何配置的包源中获得（可能它是内部包的旧版本，并且有人帮助清理了我们的本地存储库） ，似乎 NuGet 和 Visual Studio 进入某种无限（或至少长时间运行）重试循环。

如果我们从命令行运行 NuGet 安装命令，我们会返回错误

>.nuget\NuGet.exe install project\packages.config -o packages
Unable to find version '1.0.0.1' of package 'my.internal.package'.

但看起来这似乎没有被 Visual Studio/NuGet 正确使用。

  • NuGet 是否在任何地方记录其操作？
  • 我们能否限制 NuGet 还原重试或超时（可能在nuget.targets文件中？）
  • 看起来好像没有使用 NuGet 的语义版本控制，因为在我们上面的场景中 1.0.0.2 可以从 repo 中获得，可以启用吗？
4

2 回答 2

2

这似乎类似于这个问题http://nuget.codeplex.com/workitem/2970 对我有用的临时解决方法是打开 nuget.targets 并替换
<!-- 我们需要确保在程序集解决之前恢复包 - >
<ResolveReferencesDependsOn Condition="$(RestorePackages) == 'true'">
RestorePackages;
$(ResolveReferencesDependsOn);
</ResolveReferencesDependsOn>
与

<BuildDependsOn Condition="$(RestorePackages) == 'true'">
RestorePackages;
$(BuildDependsOn);
</BuildDependsOn>

在 VS 中关闭并重新加载解决方案。这将使构建依赖于恢复包，而不是似乎可以解决问题的程序集解析。

希望这可以帮助。

于 2013-01-29T07:17:35.063 回答
0

首先，您的版本控制不符合 nuget 的建议，即 1.2.3。因此，您应该尝试将您的版本升级为 1.0.1 以查看是否可以解决问题。

  • NuGet 是否在任何地方记录其操作？

您可以在命令行“nuget install”中使用 -verbosity 标志来获取更多信息。详细信息也可在输出窗口中找到。从下拉列表中选择“包管理器”。更多使用 devenv /log

  • 我们能否限制 NuGet 恢复重试或超时（可能在 nuget.targets 文件中？）

不知道这里有什么办法。

  • 看起来好像没有使用 NuGet 的语义版本控制，因为在我们上面的场景中 1.0.0.2 可以从 repo 中获得，可以启用吗？

这可以通过检查工具->选项->包管理器中的“自动检查升级”来实现？查看您的 packages.config 是否将版本限制为 1.0.0.1

于 2013-02-04T11:13:43.700 回答