Skip to content

Clean up the Application package's DI surface#347

Merged
Vulthil merged 2 commits into
mainfrom
refactor/application-di-cleanup
Jul 22, 2026
Merged

Clean up the Application package's DI surface#347
Vulthil merged 2 commits into
mainfrom
refactor/application-di-cleanup

Conversation

@Vulthil

@Vulthil Vulthil commented Jul 21, 2026

Copy link
Copy Markdown
Owner

Summary

  • Remove the parameterless AddApplication()/AddHandlers() (guaranteed-throw) and AddFluentValidation()
    (silent no-op) overloads outright — maintainer-approved given no external consumer of this package exists
    yet — instead of obsoleting them; fix the "atleast" typo in the shared exception text on the surviving
    AddHandlers(HandlerOptions).
  • PublicAPI.Shipped.txt is untouched; PublicAPI.Unshipped.txt carries the three *REMOVED* markers, and a
    new CompatibilitySuppressions.xml suppresses the resulting CP0002 findings against the 1.1.0 baseline.
  • Delete dead internal plumbing: IRequestHandlerBase's untyped HandleAsync(object, ...) wrapper and
    NotificationHandlerExecutor.HandlerInstance (written, never read).
  • Hoist per-dispatch allocations: PipelineHandlerDecorator materializes its reversed behavior chain once
    per scoped instance; the domain-event wrapper drops the same LINQ overhead where correctness allows;
    RequestLoggingPipelineBehavior/DomainEventLoggingPipelineBehavior hoist typeof(...).Name to static
    readonly fields.
  • Cache FluentValidationAssemblies/HandlerAssemblies instead of reallocating a read-only copy on every
    access; document the two-level registration model — AddApplication(Action<ApplicationOptions>) is the
    host's composition entry point, while AddHandlers(Action<HandlerOptions>) and
    AddFluentValidation(Action<FluentValidationOptions>) are supported modular entry points a project that
    doesn't own the host can call directly and additively — in XML remarks and a new docs/articles/cqrs-pipeline.md
    subsection; add the missing = default to IDomainEventPublisher.PublishAsync's CancellationToken
    parameters (PublicAPI.Shipped.txt text-only edit).

Verification

  • Full solution build (56 projects, incl. samples): clean, 0 warnings/errors — no in-repo caller
    referenced the removed members.
  • Vulthil.SharedKernel.Application.Tests: 29/29 passed on net9.0 and net10.0, including a new test proving
    AddApplication + a second module's AddHandlers/AddFluentValidation calls compose additively without
    duplicating the shared ISender/IDomainEventPublisher registrations.
  • Clean dotnet pack -c Release (fresh obj/bin) for Vulthil.SharedKernel.Application: succeeded with
    the CompatibilitySuppressions.xml in place; reproducibly failed with 6 CP0002 errors without it.
  • PublicAPI.Shipped.txt unchanged except the two PublishAsync lines gaining
    = default(System.Threading.CancellationToken); the three removed members are marked in
    PublicAPI.Unshipped.txt instead.

Backport to v1.0: no — removals and guidance ship with the next minor.

Vulthil added 2 commits July 21, 2026 20:58
… them, and document the two-level registration model
@Vulthil
Vulthil merged commit c5ec1dc into main Jul 22, 2026
7 checks passed
@Vulthil
Vulthil deleted the refactor/application-di-cleanup branch July 22, 2026 11:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant