It seems private setters inside classes that entity models inherit from cause bizarre issues with EFCore migrations. Consider the following example, where there are multiple classes (Bar
and Baz
) that inherit from Foo
. When running Add-Migration
commands multiple times (add/remove the private
modifier`), the generated schema is just wrong in multiple ways.
Created
property is set to be a dropped columnCreated
properties are set to be removed (and not replaced/renamed with anything).It's my understanding that EFCore tools don't really treat properties with private setters with any special care. Is this a wrong assumption? If so, why do some private setters work on base classes, but not others? I'm assuming this is a bug in the EF Tools, perhaps related to how it treats naming on properties, considering I have other properties with similar names in the model which might be confusing the tools
public class Context : DbContext
{
public DbSet<Bar> Bars { get; set; }
public DbSet<Baz> Bazs { get; set; }
}
public class Bar : Foo { }
public class Baz : Foo { }
public abstract class Foo
{
protected Foo()
{
Created = DateTimeOffset.UtcNow;
}
public DateTimeOffset? Created { get; private set; }
public DateTimeOffset? Updated { get; set; }
}
Edit -> It seems private setters for DateTimeOffset cause EF Tools to never map them in base classes. However, I have a string property with a private setter with [Required]
and [StringLength]
attributes, along with builder.Entity<Foo>().HasAlternateKey(x => x.RequiredStringProperty);
In that case, EF absolutely maps the property...but only with some of the classes that are inheriting from Foo
.
The EF core tools will map private setters of base classes only under certain conditions.
For example, if you have builder.Entity<Bar>().HasAlternateKey(x => x.Created);
, then EF tools will map the Created
property regardless of whether it has a private or public setter.