【问题标题】:How to force visual studio to check for broken file references at compile time如何强制 Visual Studio 在编译时检查损坏的文件引用
【发布时间】:2020-07-30 01:34:14
【问题描述】:

这个问题专门针对file references

我的项目引用了库 A。库 A 引用了库 B。 如果我不添加对库 B 的直接引用,项目将正常编译,但在尝试加载库 A 时会在运行时抛出“无法加载文件或程序集 B”异常。

那么,我如何强制 Visual Studio 在编译时检查所有损坏的文件引用?或者,有没有其他方法可以找到这些损坏的引用(工具、VS 扩展等)

这是一个重现该行为的示例项目。 https://github.com/RaikolAmaro/BrokenDependencies

【问题讨论】:

  • 据我所知,恐怕没有选项可以强制 VS 在编译时检查所有损坏的文件引用。顺便说一句,我也在我这边进行了测试,但没有收到您上面提到的错误,您能否与我分享一个可以重现此问题的简单示例?我会去检查的。
  • 这让我很吃惊。我可以在我正在从事的工作相关项目中重现它。我认为我所描述的足以重现它,但也许我遗漏了一些东西。我将创建一个小示例,并在此处为您发布。
  • @KyleWang 我在主帖中添加了一个示例。您可以下载并运行控制台应用程序。
  • 感谢您与我分享此示例。我可以重现您的问题,在研究更多之后,恐怕没有办法让 VS 在编译时检查损坏的文件引用。我建议您可以直接从 VS > 帮助 > 发送反馈 > 建议功能... 向 VS 产品团队推荐此功能
  • @KyleWang 是的,我知道......我也得出了这个结论,这就是为什么我发表这篇文章的原因是希望有人能解释为什么这个功能不存在。必须等待应用程序在运行时崩溃才能发现这些问题似乎是不可接受的。

标签: c# .net visual-studio dependency-management assemblies


【解决方案1】:

这不是编译时问题,因为在编译时,所有必需的引用都存在并考虑在内。否则,它一开始就不会编译。

这是一个运行时问题,Visual Studio 不太关心 想要在输出目录中拥有什么。这就是为什么您可以完全控制要从 NuGet 包以及其他项目中复制哪些元素的原因。为什么?因为您可能正在使用安装程序或打包解决方案,或者有一些神奇的程序集解析代码来查找您的依赖项。您可能依赖于插件或基于配置的依赖注入。太多的事情会阻碍这样的扫描。

还有一个问题。虽然程序集可能依赖于某个其他程序集,但您的代码可能不需要它。情况就是这样,如果您的代码从不加载需要此其他程序集的代码路径,那么您不需要在输出目录中运行它。

有一些工具可以扫描项目中的所有代码路径、它们所依赖的程序集等等。这些可用于查看您是否拥有运行代码所需的所有二进制文件。

这些工具有问题。上面提到的同样的问题。如果您通过配置或约定(例如基于反射)使用依赖注入或进行自己的反射,或依赖dynamic 关键字,那么这些工具可能无法找到您依赖的所有代码路径,并且可能需要一些配置或源内注释以在扫描时弄清楚。

【讨论】:

  • 感谢@jessehouwing 的回答。这种解释是我一直在寻找的,所以我会接受这个答案。也就是说,我不完全同意你所说的理由足以让 IDE 完全忽略这样的问题。至少它可以显示一个建议,让开发人员知道应用程序可能会在运行时崩溃,就像其他类型的代码异味一样。然后,开发人员可以决定忽略该建议或对其进行修复。目前的行为对我来说似乎很奇怪。
  • 对于许多项目,它可能总是会显示警告,具体取决于您的参考资料...而且这是一项计算成本很高的操作,尤其是在最初构建 Visual Studio 时。这是一个有趣的案例,可能是一个不错的扩展或 msbuild 任务。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多