Skip to content

Provide configuration for preferred team handler style #7831

Description

@DavidBoike

Describe the feature.

Convention-based handlers were introduced in NServiceBus 10.2 which allow a handler to be identified only by a [Handler] attribute. In order to provide the same scaffolding of a handler method offered by the "implement missing members" capability of most editors. The fixer has scaffolding options for both IHandleMessages style handler and for a convention-based handler with no interface.

There is currently limited ability for a team lead to require that all team members create handlers using one style or the other.

The task force that introduced convention-based handlers did 2 experiments into such a setting:

  1. Options for handler style settable via .editorconfig #7681
  2. Add HandlerStyleAnalyzer to enforce nservicebus_handler_style editorconfig setting #7682 (which was an extension to 7681)

These experiments were abandoned to control scope. We weren't super happy with the implementation, and we thought it might be a good idea to have more end-user endpoint. We also were not able to build test infrastructure support for analyzers that react differently based on editorconfig settings.

Alternatives

Currently, the most control you can have is to ensure all handlers/sagas are decorated with attributes so that source generation is guaranteed to find all matching classes, but this does nothing to enforce one handler style over the other:

# Ensure all handlers are decorated with [Handler] to enable source generation
dotnet_diagnostic.NSB0022.severity = error
# Ensure all sagas are decorated with [Saga] to enable source generation
dotnet_diagnostic.NSB0025.severity = error

Additional Context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions