Strategy for not reinventing the wheel

[bgrainger]

There are likely to be existing analyzers or products that perform checks we would like to enforce at Faithlife. For example, I believe ReSharper gives a warning or suggestion about #35 already, and there may be an existing analyzer on NuGet that checks for a number of common Task-related pitfalls.

Should we:

• recommend that existing analyzer packages be installed, and customized for only the rules we want
• bundle an existing analyzer (as a dependency of Faithlife.Analyzers somehow?) and delegate certain rules to it
• copy/paste the code into Faithlife.Analyzers (license permitting)
• some combination of all of the above, depending on the situation?

For example, it seems pointless to try to duplicate StyleCop; our approach should be to provide the right ruleset then get projects to enable it (by including it as another analyzer).

But for one-off rules, maybe we don't want to go down a path of enabling dozens of different analyzers for just a couple of checks provided by each one. What's the right approach?

[ddunkin]

ReSharper doesn't help those of us working primarily outside Visual Studio for Windows. Rules from analyzers tied to a specific platform should be reimplemented.

[amanda-mitchell]

bundle an existing analyzer (as a dependency of Faithlife.Analyzers somehow?) and delegate certain rules to it

I suspect that by not marking PrivateAssets="all" on an analyzer dependency of Faithlife.Analyzers, we would cause it to become a dependency of everything that adds Faithlife.Analyzers.

This should be tested.

[ddunkin]

Roslynator has a number of analyzers, code fixes, and refactorings we could use.