使用Visual Studio 2017调试nuget包

Run*_*e G 15 debugging visual-studio .net-core visual-studio-2017

在Visual Studio 2015和.NET Core开发中,我们可以通过从源(例如GitHub)检索源代码到本地磁盘来调试nuget包,在global.json中添加下载源代码的源路径并引用nuget包中的我们的项目.这导致对下载的源代码中的项目的引用在当前解决方案中自动显示,从而可以轻松调试(有关此功能的更多信息,请参阅本文).

有没有人知道如何使用Visual Studio 2017做同样的事情?由于global.json不见了,我找不到任何解决方案.

Run*_*e G 4

我发现这已经成为一个流行的问题,但是,MS(就目前 Visual Studio 中的大多数时间而言)没有提出实际可以改进其产品的请求。

有一些关于如何使用 Microsoft 的参考库的帖子,但这并不适用于所有项目,而且您将调试优化的版本位,这限制了监视和步骤功能。我还觉得这种方法甚至会进一步减慢 Visual Studio 的速度。这篇文章描述了这种方法。

不过,最近我找到了解决这个问题的方法。它并不总是稳定的,但可以做的是将相关项目添加到您的项目中作为项目参考。

但以下是我所做的大部分有效的步骤:

  1. 从 github(或其他来源)克隆 nuget 包的存储库
  2. 尽最大努力找到 nuget 包是从哪个提交构建的(大多数项目都引用标签或分支,但不要指望这一点,最好比较 nuget 包和提交的日期)。
  3. 按照项目中有关如何构建它的说明进行操作,有些只是在 Visual Studio 中构建,其他可能需要更多步骤,例如在命令提示符中使用一些构建脚本。
  4. 在解决方案中添加对项目的引用,有时您还需要添加项目引用的项目,但并非总是如此。还没找到具体的规则。似乎较新的 Visual Studio 更新不需要这个。
  5. 在解决方案中引用 nuget 包的所有项目中添加对项目的引用。如果不这样做可能会导致编译器尽力(不够好)解决的冲突。

构建和调试,在输出窗口中检查是否使用了位于项目输出文件夹中的程序集。如果是,只需在引用的项目中命中断点,您就可以获得完整的调试功能。

虽然要进行一些尝试,但最终还是失败了。

可以在项目引用上创建条件以确保它们不是构建在例如发布版本中,但是请注意,更改配置需要您在更改后重新加载解决方案!