VS2015诊断与代码修复 - NuGet或VSIX或两者？

Question

When using the .NET Compiler Platform SDK Templates ( https://visualstudiogallery.msdn.microsoft.com/849f3ab1-05cf-4682-b4af-ef995e2aa1a5 )

to create a Roslyn Diagnostic with Code Fix, I get both a NuGet package and a VSIX - as stated by the readme:

"Building this project will produce an analyzer .dll, as well as the following two ways you may wish to package that analyzer:

• A NuGet package (.nupkg file) that will add your assembly as a project-local analyzer that participates in builds.

• A VSIX extension (.vsix file) that will apply your analyzer to all projects and works just in the IDE."

Now the following scenario: what if both are installed – the NuGet as part of the project (eg company policy for this project), the VSIX part of the developer's local installation (eg so she gets the analyzers for other projects too). As of today, the suggestions will show up twice for the aforementioned scenario.

Can I somehow tell VS2015 that both (NuGet/VSIX) are actually the same (and it runs once only)? Or is one approach preferred for deployment (eg NuGet) and the other (VSIX) only intended for debugging the diagnostic (more convenient than NuGet)? Is there some official guidance on this?

(Note: I work on NR6Pack)

Answer 1

We recently made a change to unify based on the analyzer name. So in the case where the VSIX analyzer and the Project analyzer both have the same AssemblyName, it will only be run once and issues will be reported only once in the error list. This change should show up in the next update for VS2015 (it didn't make it into the recently released VS 2015 CTP5 though unfortunately).

Regarding NuGet vs VSIX as a deployment mechanism choice:

• Deploying through NuGet and attaching an analyzer to a project means that the analyzer travels with the project to sourcecontrol and so it's easy to apply the same rule for the team. It also means commandline builds report the issues reported by the analyzer.
• Deploying as a VSIX means that every project in the VS and those issues wouldn't be produced through command line builds.

The way I imagine this is that most rules should be deployed through NuGet and enforced at team-level but rules that are personal preferences should probably be deployed through VSIXes.