Skip to content

Excluding vendored code

Code you don't own (a copied library, generated sources checked in, a ThirdParty folder) shouldn't be reformatted. Mark it as generated code in the root .editorconfig:

[ThirdParty/**]
generated_code = true

# Entity Framework Core migrations: generated by 'dotnet ef', regenerated rather than edited
[**/Migrations/**]
generated_code = true

EF Core's migration files (Migrations/*.cs and the model snapshot) are generated but carry no <auto-generated> header, so without this the first run reformats every one of them (291 files in one trial repository).

StyleBro's rules, the built-in rules (IDE0055, IDE0073, ...) and dotnet format's whitespace pass all skip generated code, in the build and in dotnet format. One side effect: the compiler treats generated files as nullable-oblivious unless they say #nullable enable themselves.

dotnet_analyzer_diagnostic.severity = none in that folder isn't enough: a rule turned on by its id (dotnet_diagnostic.BRO1001.severity = warning in the root) wins over it. bro migrate --write therefore writes every replacing rule as none into such a folder's .editorconfig, and it never edits files inside git submodules (folders with their own .git).

Files linked from a submodule. A project can compile files from another folder (<Compile Include="..\..\ext\Lib\Code.cs" />, or a shared .projitems). bro format never formats anything inside a git submodule (it passes --exclude with every submodule folder), so StyleBro doesn't report findings there either: the package's build targets read the submodule paths from the .gitmodules above the project, and StyleBro doesn't analyze the files in those folders. A folder that is not a submodule (a copied library) still needs the generated_code = true section above. A file a project compiles from outside the repository (<Compile Include="..\..\..\outside\Shared.cs" Link="..." />) is left alone the same way: format names it (Leaving alone: ../outside/Shared.cs (outside the repository)), puts it back if a fix reached it, and its findings don't count in --verify-no-changes. The build doesn't report them either: the package's build targets pass the repository's folder (the nearest one above the project with a .git folder or file), and StyleBro hides its findings, and those of the built-in rules it turns on (IDE0055, IDE0011, ...), in files outside it. To report them anyway, set <StyleBroRepositoryRoot>none</StyleBroRepositoryRoot> (or another folder) in Directory.Build.props. That only changes the build: bro format still leaves files outside the repository alone (it doesn't read the property), so fix them by hand or in their own repository. In a submodule's own checkout, its own files are checked: the superproject's .gitmodules above it doesn't count for it.

File-based programs. A script run with dotnet run app.cs (.NET 10) imports the repository's Directory.Build.props like any project, StyleBro's package reference included, but dotnet format can't load it, so bro format can't fix it. The package's build targets leave StyleBro's analyzers out where the SDK builds such a program (FileBasedProgram), so neither the script nor a build that runs it reports StyleBro findings there.

Files a T4 template writes. A C# file that a .tt template writes (the project lists it with <DependentUpon>Name.tt</DependentUpon> or <AutoGen>True</AutoGen>) is generated code: the template writes it again. StyleBro doesn't report findings there (nor the built-in rules it turns on), and bro format leaves the C# file next to each .tt file with the same name alone.