Analyzing generated code

Most rules do not report diagnostics in generated code, which is the expected behavior for the vast majority of projects: you cannot fix code you do not own. Some rules are the exception and always analyze generated code, as the generated file is the subject of the rule, such as the Blazor rules that work on the code generated from the .razor files.

If you want the rules to apply to generated code, set the MEZIANTOU_ANALYZER_GENERATED_CODE environment variable.

Configuration

Value	Behavior
not set, empty, or any other value	Each rule uses its own default
true (case-insensitive) or 1	Every rule analyzes and reports diagnostics in generated code

The value is added to the behavior of each rule, never subtracted from it. There is no value to opt out: the rules that always analyze generated code need it to work, and disabling them would only produce false negatives. To turn off a rule, set its severity to none in the .editorconfig file.

What is generated code

The detection is done by Roslyn, and is shared by all the analyzers. A file is considered generated when:

• its name is *.designer.cs, *.generated.cs, *.g.cs, *.g.i.cs, or starts with TemporaryGeneratedFile_,
• or it starts with an <auto-generated> comment,
• or the containing type is marked with [GeneratedCode] or [DebuggerNonUserCode],
• or the .editorconfig file sets generated_code for the file.

A partial type is considered generated only when all its declarations are.

Using an .editorconfig file instead

Roslyn supports the generated_code option, which overrides the detection above for a set of files. Unlike the environment variable, it is set per project and per path, but it applies to all the analyzers, not only to Meziantou.Analyzer:

[Generated/**.cs]
generated_code = false

Use the environment variable when you want Meziantou.Analyzer specifically to analyze everything Roslyn considers generated, and generated_code when you want all the analyzers to treat a specific set of files as regular code.

Why an environment variable

An analyzer must declare how it handles generated code from Initialize(AnalysisContext), and the options of the .editorconfig files are not available at that point: they can only be read from the analysis callbacks, which run later. An environment variable is the only configuration that can be read early enough.

This has consequences that are worth knowing:

• The compiler server caches the value. dotnet build and msbuild run the analyzers inside VBCSCompiler, which is reused across builds and keeps the environment it was started with. Run dotnet build-server shutdown after changing the variable.
• The IDEs cache it too. Visual Studio, Rider, and the C# extension of Visual Studio Code run the analyzers in their own long-lived processes. Restart the IDE after changing the variable.
• Changing the variable does not invalidate the build. It is not a compiler input, so MSBuild considers the projects up-to-date and skips the compilation. Rebuild the solution to see the new diagnostics.
• There is no MSBuild property. MSBuild can only pass environment variables to a process it starts itself, which is not the case when the compilation is delegated to the compiler server. A property would work on some machines and silently do nothing on others.