Skip to content

[Bug] Code generation produces invalid C# string literal for Scrutor-decorated keyed services in 6.0.1 #2895

Closed

Description

@elitonperoni

When using Scrutor's .Decorate<>() to decorate a service registered as ICommandHandler<TCommand, TResponse>, Wolverine 6.0.1 generates invalid C# code during runtime compilation. The generated service key contains an unescaped double-quote character, causing a compilation error at startup.
This worked correctly in 6.0.0.

Steps to Reproduce

1 Register a command handler with Scrutor decoration:

services.AddScoped<ICommandHandler<SendBidCommand, SendBidDtoResponse>, SendBidCommandHandler>();
services.Decorate<ICommandHandler<SendBidCommand, SendBidDtoResponse>, SendBidCommandHandlerDecorator>();

2 - Configure Wolverine with TypeLoadMode.Auto:

builder.UseWolverine(opts =>
{
opts.CodeGeneration.TypeLoadMode = TypeLoadMode.Auto;
// ...
});

3- Run the application and consume a message handled by the decorated handler.

Generated Invalid Code
Wolverine generates the following code, which does not compile:

// INVALID - unescaped double-quote inside string literal
var commandHandler = ServiceProviderKeyedServiceExtensions
.GetRequiredKeyedService<ICommandHandler<SendBidCommand, SendBidDtoResponse>>(
serviceScope.ServiceProvider,
"ICommandHandler"2+086d3e55674e4266aa5a200422decbfe+Decorated" // ← syntax error
);

The key "ICommandHandler"2+086d3e55674e4266aa5a200422decbfe+Decorated" is the raw internal key Scrutor generates for the decorated registration. The " inside the string is not escaped to ", breaking the generated C# source.

Expected Behavior: The generated key should be properly escaped:
"ICommandHandler"2+086d3e55674e4266aa5a200422decbfe+Decorated"

Environment:
Wolverine: 6.0.1 (works on 6.0.0)
Scrutor: (decoration via .Decorate<>())
.NET 9
Transport : RabbitMQ (WolverineFx.RabbitMQ)

Workaround
Pinning to 6.0.0 restores the previous behavior. Replacing Scrutor with a manual lambda factory registration also avoids the issue.

Activity

  1. jeremydmiller commented on May 25, 2026

    @jeremydmiller
    Member

    @elitonperoni We're not going to be able to support this most likely and you'll need to switch to pure service location. Happy to take pull requests, but I don't see this being something we can just flip a switch on.

    FWIW, we could make this work w/ the old Lamar support for Decorators where Lamar inlined the decorator construction. Scrutor does it a hokey way.

    And why in the world would you be using something like ICommandHandler<SendBidCommand, SendBidDtoResponse>, SendBidCommandHandler>() within Wolverine? That smells like a homegrown MediatR tool.

  2. jeremydmiller commented on May 25, 2026

    @jeremydmiller
    Member

    Moving this to a discussion because I don't think this is actionable

  3. locked and limited conversation to collaborators on May 25, 2026
  4. converted this issue into a discussion #2898 on May 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions