RelayCommand generates code that violates CA1708

[michaelmairegger]

Describe the bug

RelayCommand generates code that violates CA1708

private global::CommunityToolkit.Mvvm.Input.AsyncRelayCommand? editCommand;
public global::CommunityToolkit.Mvvm.Input.IAsyncRelayCommand EditCommand => editCommand ??= new global::CommunityToolkit.Mvvm.Input.AsyncRelayCommand(new global::System.Func<global::System.Threading.Tasks.Task>(EditAsync), CanEdit);

but should be:

private global::CommunityToolkit.Mvvm.Input.AsyncRelayCommand? _editCommand;
public global::CommunityToolkit.Mvvm.Input.IAsyncRelayCommand EditCommand => _editCommand ??= new global::CommunityToolkit.Mvvm.Input.AsyncRelayCommand(new global::System.Func<global::System.Threading.Tasks.Task>(EditAsync), CanEdit);

Regression

No response

Steps to reproduce

Set <AnalysisLevel>latest-recommended</AnalysisLevel> on project

The error happens on net9 onwards since analysislevel_9_recommended.global has the rule

# CA1708: Identifiers should differ by more than case
dotnet_diagnostic.CA1708.severity = warning

[RelayCommand(CanExecute = nameof(CanEdit))]
private async Task EditAsync() {}

Expected behavior

Generated code be like suggested in CA1708 description:

private global::CommunityToolkit.Mvvm.Input.AsyncRelayCommand? _editCommand;
public global::CommunityToolkit.Mvvm.Input.IAsyncRelayCommand EditCommand => _editCommand ??= new global::CommunityToolkit.Mvvm.Input.AsyncRelayCommand(new global::System.Func<global::System.Threading.Tasks.Task>(EditAsync), CanEdit);

Screenshots

No response

IDE and version

Rider

IDE version

No response

Nuget packages

• [ ] CommunityToolkit.Common
• [ ] CommunityToolkit.Diagnostics
• [ ] CommunityToolkit.HighPerformance
• [x] CommunityToolkit.Mvvm (aka MVVM Toolkit)

Nuget package version(s)

8.4.0

Additional context

No response

Help us help you

Yes, but only if others can assist

[bzd3y]

Are you sure that is violating CA1708? I think, and the documentation seems to confirm, that by default it only looks at "externally visible" members, so it might not be checking that private field. Are you getting a warning for this or did you just notice that it violated the principle?

I'm also pretty sure the analyzers ignore generated code, but maybe I just remember discussing that at some point.

But I do agree that this violates the convention of private fields being prefixed with a _ and should be changed to do that.

[michaelmairegger]

I got a warning, but today not anymore. even if I set the rule to dotnet_diagnostic.CA1708.severity=error

Yes, I agree, even generated code should follow the official guidelines.

Geat work so far on this project.