Settings.IncludeCodeGeneratedAttribute

Settings.IncludeCodeGeneratedAttribute

Marks every generated class with [GeneratedCode], so tools can tell it apart from code you wrote.

Type	bool
Default	false
Applies to	EF 6 and EF Core
Databases	All
In Database.tt?	Yes

What it does

Adds [GeneratedCode("EF.Reverse.POCO.Generator", "<version>")] above each generated class, where the version is the generator's own.

System.CodeDom.Compiler is added to the using list to go with it.

Example

Settings.IncludeCodeGeneratedAttribute = false (default)

    // Category
    public class Category
    {
        public int CategoryId { get; set; } // CategoryId (Primary key)
        public string CategoryName { get; set; } // CategoryName (length: 50)

        // Reverse navigation

        /// <summary>
        /// Child Products where [Product].[CategoryId] point to this entity (FK_Product_Category)
        /// </summary>
        public ICollection<Product> Products { get; set; } // Product.FK_Product_Category

        public Category()
        {
            Products = new List<Product>();
        }
    }

Settings.IncludeCodeGeneratedAttribute = true

    [GeneratedCode("EF.Reverse.POCO.Generator", "v4.x.x")]
    // Category
    public class Category
    {
        public int CategoryId { get; set; } // CategoryId (Primary key)
        public string CategoryName { get; set; } // CategoryName (length: 50)

        // Reverse navigation

        /// <summary>
        /// Child Products where [Product].[CategoryId] point to this entity (FK_Product_Category)
        /// </summary>
        public ICollection<Product> Products { get; set; } // Product.FK_Product_Category

        public Category()
        {
            Products = new List<Product>();
        }
    }

When to use it

Code coverage. Coverlet, dotCover and Visual Studio's analyser all exclude [GeneratedCode] types by default. Without it, a hundred entity classes with untested property setters drag your coverage figure down and tell you nothing.

Static analysis. Many Roslyn analysers and StyleCop rules skip generated code when it is marked. This is the standard mechanism, and it is more precise than Settings.UseResharper because it works per class and for any tool, not just ReSharper.

Auditing. The attribute records which version of the generator produced the file, which is genuinely useful when a bug turns out to be a generator bug.

Leave it off if none of your tooling reads it. It is one line per class doing nothing.

Gotchas

Some tools want <auto-generated> instead, and the generator already writes that. The comment on the first line of every generated file is the other convention, and Roslyn's own "is this generated?" check reads it. If your analyser is already skipping the file, you may not need this attribute at all.

The version is baked in at generation time. Regenerate with a newer generator and every class changes, which makes for a large and uninformative diff. That is a real cost if you regenerate often.

[GeneratedCode] does not stop the compiler. Warnings and errors from generated code still appear. For those, see Settings.UsePragma.

It goes on classes, not on members. Individual properties are not marked.

Do not confuse it with Settings.IncludeGeneratorVersionInCode, which writes the version into the file header comment and requires Settings.ShowLicenseInfo to be on as well.

See also

• Settings.IncludeGeneratorVersionInCode - the version in the header instead
• Settings.UseResharper | Settings.UsePragma - the other suppression settings
• Settings Reference