问使用VB/C#诊断分析器/CodeFix/AutoUpdate的多个.vsix会导致性能问题吗？

EN

Roslyn和VSIX包装的注意事项：

As https://roslyn.codeplex.com/discussions/549445 by https://www.codeplex.com/site/users/view/srivatsn

1. 同时引用Microsoft.CodeAnalysis.CSharp和Microsoft.CodeAnalysis.VisualBasic的扩展将

- Load both the compilers even if we try to open a C# project, this is not ideal.

​

1. 如果我们必须分析符号ISymbolAnalyzer，在这里您只分析符号而不是语法节点，那么我们应该采用单一的语言无关分析器。这意味着我们不需要引用任何C#/VB (甚至微软也在考虑实现更多语言无关的分析器)。包含两个导出属性--每个语言一个，这些属性告诉VS在解决方案中包含相应语言时实例化和调用这些分析器。
2. 编译作为一个过程在编译完成后会留下内存，但是由于几乎每次击键都会发生编译，如果分析器同时引用c#和VB，则会将这两个编译器带入内存。由于具有持久性特性，如果解决方案下有一个大型项目(这是我的典型生产场景)，则可能会出现问题。
3. 在调用相应的语法方法时，还是在导出分析器的实例化(通过MEF导出属性通过相应的语言用例进行筛选)时，编译器是否被加载是一种困惑，因为他还提到，引用这两种语法节点的if方法可能会使JIT编译并加载dll。
4. 任何链接到菜单命令的分析器都是VS特定的，如果它们被链接到项目，那么它也将参与构建，甚至通过MSBuild参与VS之外的构建。
5. VSIX应该能够导出多个组件来扩展这两个扩展点。

As http://blogs.msdn.com/b/ericlippert/archive/2012/06/08/persistence-facades-and-roslyn-s-red-green-trees.aspx by https://www.codeplex.com/site/users/view/VSadov

1. 语法树数据结构的持久性和每次击键时都需要重做分析(增量编译:这是Srivatsn的编译方法)，使他们设计了红绿树方法，这有助于增量编译的性能。

As https://stackoverflow.com/questions/25262618/can-multiple-vsix-with-vb-c-diagnostic-analyzer-codefix-autoupdate-cause-perfo/25270233#comment39362585_25262618 by https://stackoverflow.com/users/34397/slaks

1. MEF出口无论是否打包在单个VSIX中都没有任何区别(但应该注意的是，将两个类型分析器合并到一个单独的程序集(即MEF导出)存在性能问题)。

As https://stackoverflow.com/questions/25262618/can-multiple-vsix-with-vb-c-diagnostic-analyzer-codefix-autoupdate-cause-perfo#comment39383014_25270233 by https://stackoverflow.com/users/678625/kevin-pilch-bisson

1. 尽管这些程序集在哪里打包并不重要，除非它们在涉及特定于语言的引用时是分开的。
2. 如果分析器同时引用C#和VB特定的Roslyn程序集，并且这些编译器程序集很大，则将保留虚拟内存。
3. 性能问题是磁盘加载和JIT成本(如果不存在编译和引用，我不确定JIT成本如何)，但是由于保留了地址空间，VS中可能会出现问题(我不确定这将是一个问题)。
4. 据他说，微软所做的是创建三个项目来解决这个问题(根据Srivatsn的说法，微软仍在尝试语言不可知论的分析器)。

- Shared (_No language specific binaries in it_)
- C# specific (_+ shared libraries_)
- VB Specific (_+ shared libraries_)

​

1. 如果没有引用特定于语言的二进制文件，如果MEF导出被适当地归因于ContentType或LanguageName，那么上述问题就可以得到解决。
2. 我们可以将额外的程序集捆绑到单个VSIX中(通过将其他项目嵌入其中)，并且VS将独立地加载每个程序集。

最后执行：

因此，在与我的团队讨论后，我最终得出了如下结论：

• 通过在it 中嵌入以下项目来实现单个VSIX
  • 更新插件
    • 检查过去7天是否有最新情况
    • 然后通过JSON请求从服务器端检查插件的版本号
    • 然后从服务器下载插件，将下载日期存储在VS设置中，以便进行初始检查。
    • 禁用先前的插件。
    • 卸载之前的插件。
    • 安装新插件
    • 此功能是在时触发的
      • VS负载
      • 手动菜单命令(应该覆盖下载日期检查)

​

​

- C# plugin  
    - Implements and refers only rules for C# 

​

- VB Plugin  
    - Implements and refers only rules for VB

​

​

不是的。

唯一真正的“性能问题”是将C#和VB放在同一个程序集中(注意，而不是VSIX)，这意味着当我们必须加载一个程序集时，加载其他程序集。

从MEF的角度来看，我们只是得到了一份出口清单:我们不知道它们来自哪个VSIXes，即使我们想要，也很难搞清楚。因此，您将哪些内容放入VSIX并不重要:根据对用户有意义的内容来划分它们。