为 Visual Studio 编写解决方案分析器 [英] Writing solution analyzers for Visual Studio

查看:34
本文介绍了为 Visual Studio 编写解决方案分析器的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

所以我需要的是为什么要为 Visual Studio 编写解决方案分析器,它可以:

So what I need is some why to write a solution analyzer for Visual Studio, that can:

  • 检测移动类和移动方法重构.
  • 在 Visual Studio 中显示推荐的重构.
  • 应用重构.

我有一个可以执行此操作的控制台应用程序(使用 Roslyn 编译器),但我想将逻辑集成到 Visual Studio 中.从我所读到的内容来看,当前的代码修复/重构/分析器仅支持文档级别的重构,但对我而言,这些信息不足以推荐上述重构之一.我需要有关整个解决方案的信息.

I have a console application that can do this (using the Roslyn compiler), but I want to integrate the logic inside Visual Studio. From what I have read, the current code fix/refactoring/analyzers support only document level of refactoring, but for me that is not enough information to recommend one of the mentioned refactorings. I need information about the whole solution.

所以我的问题是最好的方法是什么?你能推荐一个起点吗?一些与该主题相关的文章?任何建议都会对我有很大帮助.

So my question is what is the best way to do this? Can you recommend a starting point? Some articles related to the topic? Any advice would help me a lot.

推荐答案

简短回答: Roslyn API 没有合理的方法来做到这一点

Short Answer: There is no reasonable way to do this with the Roslyn API

长答案:

当前实现的 api 仅允许分析器了解当前编译(Visual Studio 中的一个项目)中的内容.如果您从分析器的 Initalize 方法中调用 RegisterCompilationAction,您将能够查看编译中的所有符号.

The api as it is currently implemented only allows analyzers to know about things in the current compilation (a project in Visual Studio). If you call RegisterCompilationAction from within the Initalize method in your analyzer, you will be able to look at all the symbols within the compilation.

为什么分析人员看不到整个解决方案的范围?最简单的答案是:因为编译器不能,而分析器在编译器内部运行.这样做是为了使分析器可以在没有安装 Visual Studio 的情况下在持续集成服务器上运行.MSBuild 读取解决方案文件,然后为每个项目调用一次编译器.编译器从不知道项目依赖关系,编译器团队也不想从事该业务,他们很乐意将其留给 MSBuild.

Why can't analyzers see the scope for an entire solution? The simplest answer is: because the compiler can't, and analyzers run inside the compiler. This is done so that analyzers can be run on continuous integration servers without Visual Studio installed. MSBuild reads the solution file and then invokes the compiler once for each project. The compiler is never aware of project dependencies and the compiler team does not want to be in that business, they are happy to leave it to MSBuild.

人们试图通过使用 MSBuildWorkspace 加载他们的解决方案并尝试以这种方式跨项目查看文档来解决这个问题.这偶尔会失败,因为 MSBuildWorkspace 不是线程安全的.它还会导致内存使用量猛增.人们已经尝试缓存 MSBuildWorkspace 实例来部分解决这个问题,但是每次创建新编译时缓存都需要失效(基本上是在除最微不足道的更改之外的所有情况下).基本上,沿着这条路走下去会充满痛苦,而且没有得到支持.

People have tried to work around this by loading their solution using MSBuildWorkspace and attempting to look at documents across projects that way. This will fail occasionally because MSBuildWorkspace is not thread-safe. It will also cause memory usage to skyrocket. People have tried to cache MSBuildWorkspace instances to partially resolve this problem but the cache needs to be invalidated every time a new compilation is created (essentially in the event of all but the most trivial changes). Basically, going down this path is rife with pain and is unsupported.

有足够多的人要求此功能,我们认为我们最终需要这样做.除非您愿意编写一个导入 Visual Studio 工作区并尝试运行其自己的分析引擎的 Visual Studio 扩展,否则目前没有合理的方法来完成它.请在 https://github.com/dotnet/roslyn

Enough people have asked for this feature that its something we think we need to do eventually. There is no reasonable way to accomplish it today unless you are willing to write a Visual Studio extension that imports the Visual Studio Workspace and attempts to run its own analysis engine. Please file feature request on https://github.com/dotnet/roslyn

这篇关于为 Visual Studio 编写解决方案分析器的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆