我正在实施一个系统，该系统将实现代码质量作为内部质量措施的一部分。我用两种可能的实现方式构建了系统，如下所示：
实施1 :(已实施）
AutoUpdate功能通过验证其版本号来检查自身和其他CodeQuality插件的任何更新。一旦更新了CodeQuality插件，它将停止接下来7天的更新。
这是我目前的实现想法，但是由于此实现中与扩展数量相关的可能的性能问题以及可能存在Visual Studio对其使用/性能的限制（如上所述）团队）
实施2 :(建议）
在此，更新功能是单独触发的，并保持单一责任理念。
我不确定AutoUpdate项目（使用菜单命令模板）和C＃/ VB CodeFix / DiagnosticAnalyzer项目（Roslyn模板）是否可以共存？
实施3 :(其中一个意见）
我甚至不确定这三个是否可以在一个vsix中共存。
所以我的问题可能是上述三种场景中的性能问题，以及我们如何将基于Roslyn模板开发的插件实现为visual studio的普通菜单命令模板扩展。
--- --- EDIT 总结要求如下
共存：VSPackage扩展（用于扩展Visual Studio的shell命令组件）和Managed Extensibility Framework / MEF扩展（用于自定义和扩展编辑器以包含Roslyn DiagnosticAnalyzer / CodeFix），
中共存性能：共存不应影响性能，VSPackage扩展所处理的AutoUpdate不应创建冗余服务调用。
答案 0 :(得分：2)
没有
你可以拥有的唯一真正的“性能问题”是将C＃和VB放在同一个程序集中（注意，而不是VSIX），这意味着当我们必须加载一个时，我们加载其他组件。
从MEF的角度来看，我们只得到一份出口清单：我们不知道它们来自哪个VSIX，而且即使我们想要也很难弄明白。所以你放入的VSIX根本不重要：根据对用户有意义的东西进行划分。
答案 1 :(得分：1)
引用Microsoft.CodeAnalysis.CSharp和Microsoft.CodeAnalysis.VisualBasic的扩展程序
如果我们必须分析符号ISymbolAnalyzer，你只是在分析符号而不是语法节点，那么我们应该采用一个与语言无关的分析器。这意味着我们不必引用任何C＃/ VB dll（即使Microsoft正在考虑实现更多与语言无关的分析器）。包括两个导出属性 - 每种语言一个，当解决方案中包含相应的语言时，这些属性告诉VS实例化并调用这些分析器。
编译作为一个进程在编译完成后离开内存，但由于几乎每次击键都会发生编译，如果分析器同时引用c＃和VB，它会将两个编译器都带入内存。由于存在持久性特征，如果解决方案下存在大型项目（这是我的典型生产方案），则可能会出现问题
在调用相应的语法方法时或在导出的分析器实例化时，是否加载了编译器（通过提及相应的语言用例再次通过MEF导出属性进行过滤） ）因为他还提到if引用这两种语法节点的方法可能会使JIT编译并加载dll。
链接到菜单命令的任何分析器都是VS特定的，如果它们链接到项目，那么它也将参与构建，甚至在VS之外通过MSBuild
VSIX应该能够导出多个组件以扩展这两个扩展点。
据他所说，微软所做的是创建三个项目来解决这个问题（据Srivatsn称，微软仍在尝试使用与语言无关的分析器）
如果没有引用特定于语言的二进制文件，并且MEF导出是否适当地归因于ContentType或LanguageName，则可以解决上述问题
所以最后我在与我的团队讨论后得出结论如下