Options for handler style settable via .editorconfig

[DavidBoike]

This pull request introduces a new nservicebus_handler_style option with values of either IHandleMessages or Conventions to the .editorconfig file that control which fixers are allowed to scaffold an NServiceBus message handler when the [Handler] attribute is applied to a class:

[Handler]
public class MyNewHandler
{
}

When either of these options is set in .editorconfig, it determines the preferred organization for NServiceBus message handlers within the codebase. This centralized configuration allows project maintainers to suggest a consistent handler structure across the codebase, streamlining code reviews and onboarding for contributors.

Because .editorconfig files are hierarchical, project maintainers can control which styles are preferred in different parts of the codebase, if there are differences.

No setting (default)

When no setting is used, both fixers are available:

1. Implement IHandleMessages<MyMessage>
2. Add convention-based Handle(MyMessage, ...)

IHandleMessages only

When the .editorconfig file contains:

nservicebus_handler_style = IHandleMessages

Then only the Implement IHandleMessages<MyMessage> code fix is available.

Conventions only

When the .editorconfig file contains

nservicebus_handler_style = Conventions

Details

• Evaluation of the setting value (IHandleMessages or Conventions) is case insensitive.

Then only the Add convention-based Handle(MyMessage, ...) code fix is available.

[DavidBoike]

@copilot This feature is potentially incomplete. By controlling which code fixes can be used, it only suggests the NServiceBus handler style for new message handlers as they're being written, but does nothing to help a project maintainer enforce a handler style for handlers that already exist or that a developer types up manually.

Could you please raise a PR on top of this PR to add an additional analyzer to enforce this if the .editorconfig file contains the nservicebus_handler_style setting. Keep in mind:

• Follow the established conventions for Roslyn analyzers already in use in this project.
• Put the class for the new analyzer in the Handlers directory of the NServiceBus.Core.Analyzer project.
• As a very first step in the analyzer, we should check the setting, because if there is no handler style setting, we should return early.
• Add the DiagnosticId and Diagnostic in the same place as the rest of them in the project.
• A diagnostic should be raised both for a class implementing IHandleMessages when the setting is Conventions, and for a class marked [Handler] that does not implement IHandleMessages when the setting is IHandleMessages.
• Sagas should be filtered out, since Sagas (even though they implement IHandleMessages) don't support convention-based identification.
• Don't worry about adding tests for now, because our analyzer testing framework doesn't have the capability of injecting editorconfig settings.

[Copilot]

@DavidBoike I've opened a new pull request, #7682, to work on those changes. Once the pull request is ready, I'll request review from you.

[DavidBoike]

Closing, as I'm not sold that this is the way to go about this, plus it's not 100% not necessary and could be added later in a minor.