Migrations are not ignored by code analyzers

[salaros]

Code-first DB migrations shall be excluded from StyleCop/FxCop etc analysis

Please consider adding the following comment to ALL migration-related files

// <auto-generated/>

[ajcvickers]

Duplicate of #10203

[hades200082]

These days you can add the following to your .editorconfig file (adjust the file path in the square brackets as needed)

# Do not apply code styles to generated migration files
[**/Migrations/*.cs]
generated_code = true

[salaros]

@hades200082 that's cool, but it feels like adding a comment because

• it's more correct, because it's a de-facto standard
• it's semantic, because it IS an autogenerated file
• it works out of the box

[hades200082]

@salaros There is a semantic meaning to the <auto-generated/> annotation already defined by Microsoft in the Roslyn analyzers.

It's a special marker typically placed at the top of code files that are automatically generated by a tool or a build process. It serves as a signal to developers and tools that the file is not intended to be manually edited, as any changes made to it may be overwritten the next time the file is regenerated.

It's that second bold part that's the problem here - the file is not intended to be manually edited - because EF Migrations are intended to be manually edited after generation. That's why they don't carry this annotation by default.

Thus, if you want to exclude them from code analysis you need to do one of the following:

1. Manually edit each file to add the annotation (usually undesirable)
2. Add some code to your migrations project that prefixes the generated files as discussed in #10203
3. Add the section I mentioned above to your .editorconfig file

I prefer the last option as it means I don't need extra code in my projects and the .editorconfig is checked in anyway for my team AND its what configures & drives my code analysis tools anyway.