LAMA0035: Two aspect layers aren't explicitly ordered

Cause

When several aspects transform the same code, their order matters. You specify this order with the AspectOrderAttribute assembly-level custom attribute. When the order of two aspects isn't specified, Metalama orders them alphabetically. This order is deterministic, but it may not be the order you need.

By default, Metalama accepts unordered aspects. When the MetalamaRequireOrderedAspects option is enabled, Metalama instead checks, while it executes the aspect layers one after the other, that each layer is explicitly ordered after the previous one. It reports LAMA0035 for each pair of consecutive layers whose order results only from the alphabetical fallback. In the message, <Layer1> and <Layer2> are the two layers, in the order in which Metalama executed them. A layer is identified by the full name of the aspect class, followed by the layer name when the aspect has several layers.

The check covers all aspect layers known to the project, including the layers of aspects defined in referenced aspect libraries. The diagnostic has no location in source code.

This diagnostic isn't shown in an example: with MetalamaRequireOrderedAspects enabled, Metalama checks every pair of aspect classes visible to the project, including those of referenced aspect libraries, so in the documentation's test project, which references many of them, it reports dozens of unrelated pairs.

Resolution

Do one of the following:

• Add an [assembly: AspectOrder(...)] attribute that orders the two layers named in the message, then build again: Metalama reports the next unordered pair, if any. For details, see Ordering aspects.
• If you don't need the check, disable it. Remove the MetalamaRequireOrderedAspects property from the project file or from Directory.Build.props, or set it to False:

<PropertyGroup>
    <MetalamaRequireOrderedAspects>False</MetalamaRequireOrderedAspects>
</PropertyGroup>

See also

• Ordering aspects
• MSBuild properties and environment variables