Proposal: More flexible Analyzer probing rules

[Chet Husk]

I propose that we change the current Analyzer discovery mechanism to be more like the probing rules for type providers, in an effort to aid discoverability and usability of analzyers.

Currently, the analzyer probing logic is described as:

• from a given directory
• look in that directory and all subdirectories
• for any dlls named Analyzer.dll

This is brittle for a few reasons:

• it requires the analyzer assemblies to live at a common subdirectory (which often leads folks to use paket, which we may not want to force)
• it can load an analyzer incorrectly if the analyzer has multiple dlls for different target framework monikers
• it can miss analyzers if the author didn't name them correctly

Describe the solution you'd like

I propose that we adopt a directory structure similar to that of type providers, something like (assuming a package root of /)

/analyzers/<tfm>
/analyzers/runtime/<rid>-<architecture>

For a complete example see the nuget package documentation here.

The idea would be to mimic that logic, underneath a directory that specifically opts the package into analyzers.

Assuming this, the logic for discovering analyzers in tooling would be

• from the set of referenced packages in a project
• filter down to those that contain analyzers
• filter down to the correct TFM directories for the tool being run and load the dlls from those directories
• from the assemblies loaded, probe for members of type Analyzer or equivalent as we do today

Describe alternatives you've considered
An alternative would be to not do this and attempt to probe all of project dependencies, not just loading dlls from a folder. I disagree with this approach due to the immense amount of probing work that would be done, especially given the current logic of just taking every dll from every subfolder of the probed folder root.

Additional context
Add any other context or screenshots about the feature request here.

[Christer van der Meeren]

How does Roslyn do this? Is there prior art there we could take inspiration from?

As I understand it, with the proposed solution, as well as the current solution, it does not matter which project you install an analyzer into. This is confusing. When you install an analyzer as a NuGet package, I think it would make most sense to enable it for (at most, depending on the configuration) the projects where it is installed. This is how Roslyn analyzers work.

In any case, I welcome any solution that means I can just install an analyzer NuGet package into (at least) one project and have the analyzer working, free of any configuration or non-standard requirements regarding package/NuGet paths.