How do you write a Roslyn analyser, and how do you test it and ship it to a team?

How I would answer this in an interview

A Roslyn analyser is a class deriving from DiagnosticAnalyzer that registers callbacks (on syntax nodes, symbols or operations) and reports diagnostics when code breaks a rule. Writing one well means: pick the right analysis level (usually operations), make it fast and concurrent-safe, test it thoroughly with the Roslyn testing framework, and ship it as a NuGet package configured through .editorconfig so the whole team gets it in the IDE and CI.

1. Choose the rule and the level

Example rule: "Async methods must pass the CancellationToken they receive to calls that accept one" (a stricter variant of CA2016 for our own APIs), or a domain rule like "Don't call DbContext.SaveChanges() inside loops".

2. Writing it

[DiagnosticAnalyzer(LanguageNames.CSharp)]
public sealed class SaveChangesInLoopAnalyzer : DiagnosticAnalyzer
{
    public const string Id = "SGM001";
    private static readonly DiagnosticDescriptor Rule = new(
        Id, "Avoid SaveChanges inside loops",
        "'{0}' is called inside a loop; batch changes and save once after the loop",
        "Performance", DiagnosticSeverity.Warning, isEnabledByDefault: true,
        helpLinkUri: "https://wiki.internal/analyzers/SGM001");

    public override ImmutableArray<DiagnosticDescriptor> SupportedDiagnostics => [Rule];

    public override void Initialize(AnalysisContext context)
    {
        context.ConfigureGeneratedCodeAnalysis(GeneratedCodeAnalysisFlags.None);
        context.EnableConcurrentExecution();

        context.RegisterCompilationStartAction(start =>
        {
            var dbContext = start.Compilation.GetTypeByMetadataName("Microsoft.EntityFrameworkCore.DbContext");
            if (dbContext is null) return;                         // EF not referenced: nothing to do

            start.RegisterOperationAction(ctx =>
            {
                var invocation = (IInvocationOperation)ctx.Operation;
                if (invocation.TargetMethod.Name is not ("SaveChanges" or "SaveChangesAsync")) return;
                if (!InheritsFrom(invocation.TargetMethod.ContainingType, dbContext)) return;

                for (var parent = invocation.Parent; parent is not null; parent = parent.Parent)
                {
                    if (parent is ILoopOperation)
                    {
                        ctx.ReportDiagnostic(Diagnostic.Create(Rule, invocation.Syntax.GetLocation(), invocation.TargetMethod.Name));
                        return;
                    }
                    if (parent is IAnonymousFunctionOperation or ILocalFunctionOperation) return;   // stop at lambdas
                }
            }, OperationKind.Invocation);
        });
    }

    private static bool InheritsFrom(ITypeSymbol? t, INamedTypeSymbol b)
    {
        for (; t is not null; t = t.BaseType) if (SymbolEqualityComparer.Default.Equals(t, b)) return true;
        return false;
    }
}

Good practices shown: compilation-start caching of well-known types, early exits, symbol comparisons with SymbolEqualityComparer, concurrent execution, no generated-code analysis, a help link and a clear message.

3. Testing

Use Microsoft.CodeAnalysis.CSharp.Analyzer.Testing (xUnit/NUnit/MSTest adapters):

public class SaveChangesInLoopTests
{
    [Fact]
    public async Task Reports_SaveChanges_in_foreach() => await new CSharpAnalyzerTest<SaveChangesInLoopAnalyzer, DefaultVerifier>
    {
        ReferenceAssemblies = ReferenceAssemblies.Net.Net80.AddPackages([new PackageIdentity("Microsoft.EntityFrameworkCore", "8.0.0")]),
        TestCode = """
            using Microsoft.EntityFrameworkCore;
            class Repo(DbContext db)
            {
                void Save(int[] ids) { foreach (var id in ids) { {|SGM001:db.SaveChanges()|}; } }
            }
            """
    }.RunAsync();

    [Fact]
    public async Task No_diagnostic_outside_loop() => ... // negative test
}

Test: positive cases, negative cases (outside loops, inside lambdas, non-EF SaveChanges methods), edge cases (nested loops, while, do), generated code, and performance on large files.

4. Shipping it to a team

• Project: netstandard2.0, reference the minimum Microsoft.CodeAnalysis.CSharp version your team's SDK/IDE supports, EnforceExtendedAnalyzerRules.
• Package: pack the DLL into analyzers/dotnet/cs, set DevelopmentDependency=true so consumers don't get it as a runtime dependency; include a .props/.globalconfig with default severities if desired.
• Distribute via an internal feed; reference it centrally from Directory.Build.props (or Directory.Packages.props with GlobalPackageReference).
• Configure severities in .editorconfig (dotnet_diagnostic.SGM001.severity = error), allowing teams to phase in.
• Docs: a page per rule (why, how to fix, how to suppress) linked from helpLinkUri.
• Code fix provider where the fix is mechanical.
• Version carefully: new rules start as warnings or disabled; breaking severity changes in major versions.
• CI: build with TreatWarningsAsErrors for the rule set once clean.

5. A production example

Repeated performance incidents came from SaveChanges inside loops in batch jobs (thousands of round trips). We wrote SGM001 as above, shipped it in our internal analyzer package with severity warning, and the first build flagged 37 occurrences across 12 services. After teams fixed them over two sprints, we raised the severity to error. The incident class stopped, and the same package later gained rules for missing CancellationToken forwarding in our own SDK.