Roslyn analyzers are little static-analysis plugins that run during compile time and warn or error when your C# code breaks a rule. They’re what Visual Studio uses to flag unused variables, async void, or naming conventions.

In Unity projects you can treat them like any other package. Drop an analyzer NuGet (or the .dll) into an Editor folder and they’ll execute every time the editor compiles. Use them to:

  • catch expensive API calls in Update (custom rule)
  • enforce your team’s naming/style guidlines
  • prevent GetComponent in hot paths
  • require [SerializeField] on private fields meant for the inspector

A few tips:

  1. Ship a ruleset file with your repo so all team members get the same warnings.
  2. If a rule is too noisy, tune its severity instead of just disabling it; documentation or info is better than none.
  3. You can write your own analyzer using the Roslyn SDK. A simple DiagnosticAnalyzer class can detect patterns and point at the line with a helpful message.
  4. When using analyzers in Unity, remember the assembly definition structure: place the analyzer in an editor-only asmdef so it doesn’t bloat player builds.

The payoff is immediate feedback in the IDE and CI: you can enforce clean code practices before the code ever lands in the repo. The trick is to keep the rules useful and not just another red squiggle nobody fixes.

The magic: analyzers let the compiler be your stylist. They catch granularity issues you don’t want to code-review manually and keep bad patterns out of your game loop without runtime cost.

https://www.meziantou.net/using-roslyn-to-analyze-and-rewrite-code-in-a-solution.htm