Fix S1144 FP: When having read only Id properties on entity types in EF Core

[mary-georgiou-sonarsource]

Description

In EF Core, once properties are being set via the constructor, it can make sense to make some of them read-only. EF Core supports this, but there are some things to look out for:

• Properties without setters are not mapped by convention. (Doing so tends to map properties that should not be mapped, such as computed properties.)
• Using automatically generated key values requires a key property that is read-write, since the key value needs to be set by the key generator when inserting new entities.

An easy way to avoid these things is to use private setters.
Although the setters seem unused, in reality, EF Core is using the field in an extralinguistic manner.

See MSDN docs for more information.

Repro steps

public class Blog
{
    public Blog(int id, string name,)
    {
        Name = name;
    }

    public int Id { get; private set; }            // FP
    public string Name { get; private set; }
}

Expected behavior

It should not raise for properties on classes representing entities in EF core that have unused private setters.

[gsaltd-core]

I noticed a test has been created for this, but it hasn't yet been fixed. Is this likely to be fixed soon as we are having to supress this error.

[guimabdo]

I think not only EF Entity Ids. When desiging an Entity in EF you may want to have any other property that is filled from a database column that is set from outside the application and should not be changed in the code.

And not only EF, you may want to desserialize a JSON into a class object that should not allow setting properties in the code. The serializer needs the private setters.

[martin-strecker-sonarsource]

This problem is quite universal for all kinds of serializations:

• Binary serialization (see the exceptions section in S1144)
• Automapper - Configuring visibility
• Csv Helper - IReaderConfiguration
• Dapper
• DataContractSerializer
• and most of the other serializers out there

I think we need something more flexible to fix this issue, like e.g. what Re-Sharper does with the UsedImplicitlyAttribute.

[mary-georgiou-sonarsource]

FYI - we'll consider this ticket for the next planning.
I'll update here when I have something more concrete about when it will be tackled.