LAMA0877: A [Durable] member must not be writable from outside its type

Cause

When you apply [Durable] (from the Metalama.Framework.Utilities namespace) to a field or an automatically implemented property whose declared type isn't durable, such as an interface, object, or a delegate, the analyzer stops checking the declared type. It checks instead that every value assigned to the member is durable. This is the form to use when the declared type can't vouch for the value.

This exchange is sound only if the analyzer sees every assignment. Code in another assembly, or in a friend assembly granted access with InternalsVisibleTo, could assign a value that this compilation never contains, so nothing would check the guarantee.

The analyzer reports LAMA0877 on a field or property that carries [Durable] when it can be written from outside its declaring type. This is the case for a field that is neither readonly nor private, and for a property that has a setter or an init accessor that isn't private. An internal member is also reported. The rule applies even if the declaring type isn't itself durable. In the message, <Member> is the name of the member, and <Type> is its declaring type.

This diagnostic is reported by a Roslyn analyzer, which snapshot tests of aspects don't run, so it can't be shown in an example.

Resolution

Confine all assignments to the declaring type, in one of the following ways:

• Add the readonly modifier to the field.
• Make the field private.
• Make the property read-only (no setter), or give it a private setter.

An init accessor isn't enough, because the object initializer that uses it can be in any assembly.

See also

• LAMA0876
• Diagnosing memory leaks caused by compile-time code