Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: More flexible Analyzer probing rules #32

Open
baronfel opened this issue Jan 7, 2021 · 1 comment
Open

Proposal: More flexible Analyzer probing rules #32

baronfel opened this issue Jan 7, 2021 · 1 comment

Comments

@baronfel
Copy link
Collaborator

baronfel commented Jan 7, 2021

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.

@cmeeren
Copy link
Contributor

cmeeren commented Jan 2, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants