We should consider adding an analyzer and code fix that adds an informational diagnostic when you're using metadata attributes that will be ignored due to the current selected MetadataSource. We could also add a code fix that automatically sets the "correct" value in the MetadataSource.
Background
In #163 we added support for [EnumMember]. This also changed the behaviour of metadata attributes to only allow using a single metadata attribute, i.e. either [EnumMember], [Display] or [Description]. You select the metadata type by either setting the MetadataSource property in the [EnumExtensions] attribute:
[EnumExtensions(MetadataSource = MetadataSource.DisplayAttribute)]
public enum EnumWithDisplayNameInNamespace
{
First = 0,
[Display(Name = "2nd")]
Second = 1,
Third = 2,
}
Or by setting it globally as a fallback:
<PropertyGroup>
<EnumGenerator_EnumMetadataSource>DisplayAttribute</EnumGenerator_EnumMetadataSource>
</PropertyGroup>
and finally we fallback to [EnumMember]
Required Analyzer behaviour
The analyzer should identify cases where an enum decorated with [EnumExtensions] (which hasn't specified MetadataSource) has members that are using metadata attributes which will be ignored. For example the following would be identified, because the default source is [EnumMember], but this uses [Display]:
[EnumExtensions]
public enum EnumWithDisplayNameInNamespace
{
First = 0,
[Display(Name = "2nd")]
Second = 1,
Third = 2,
}
If the user had specified [EnumMember] anywhere in this type, the [Display] attribute would not be flagged.
Note that the "default" value must be calculated using the fallback MSBuild variable.
Required Code fix behaviour
For cases we identify, we should provide a code fix that automatically adds the appropriate MetadataSource property value to the [EnumExtensions] attribute for the type, or allows setting the value globally as an MSBuild property.
Implementation
Follow the existing analyzer examples. Make sure to add unit tests to NetEscapades.EnumGenerators.Tests to confirm all the expected behaviours, using the same testing helpers already used in the project.
We should consider adding an analyzer and code fix that adds an informational diagnostic when you're using metadata attributes that will be ignored due to the current selected MetadataSource. We could also add a code fix that automatically sets the "correct" value in the
MetadataSource.Background
In #163 we added support for
[EnumMember]. This also changed the behaviour of metadata attributes to only allow using a single metadata attribute, i.e. either[EnumMember],[Display]or[Description]. You select the metadata type by either setting theMetadataSourceproperty in the[EnumExtensions]attribute:Or by setting it globally as a fallback:
and finally we fallback to
[EnumMember]Required Analyzer behaviour
The analyzer should identify cases where an enum decorated with
[EnumExtensions](which hasn't specifiedMetadataSource) has members that are using metadata attributes which will be ignored. For example the following would be identified, because the default source is[EnumMember], but this uses[Display]:If the user had specified
[EnumMember]anywhere in this type, the[Display]attribute would not be flagged.Note that the "default" value must be calculated using the fallback MSBuild variable.
Required Code fix behaviour
For cases we identify, we should provide a code fix that automatically adds the appropriate MetadataSource property value to the
[EnumExtensions]attribute for the type, or allows setting the value globally as an MSBuild property.Implementation
Follow the existing analyzer examples. Make sure to add unit tests to NetEscapades.EnumGenerators.Tests to confirm all the expected behaviours, using the same testing helpers already used in the project.