EasyNetQ反序列化失败：typeName为null的原因与解决方法

typeName的来源 #

在EasyNetQ 6.x中，ITypeNameSerializer依赖的typeName，默认是从AMQP消息的Headers头字段里的type键获取的，不是从消息体的JSON属性里读。如果是用EasyNetQ自带的生产者发送消息，它会自动把消息对应的CLR类型的「全名+程序集名称」塞进这个type头里，供消费者端的序列化器映射到具体类型。

typeName为空的原因 #

1. 生产者没加AMQP消息头的type字段
   要是消息是用原生RabbitMQ客户端或者非EasyNetQ的工具发送的，大概率不会自动添加这个type头字段，消费者自然拿不到typeName。你之前在消息体里加type或typeName属性没用，就是因为EasyNetQ默认不读消息体里的类型标识。

2. 自定义序列化器注册错了地方
   EasyNetQ有自己的内部依赖注入容器，如果你只在ASP.NET Core的DI容器里注册AcceptedTypeNameSerializer，没替换EasyNetQ内部的ITypeNameSerializer实现，那自定义逻辑根本不会生效，还是用默认的，自然拿不到正确的typeName。

3. 序列化配置冲突
   要是你配置了其他序列化方式（比如Protobuf），或者修改了EasyNetQ的默认类型解析规则，可能会导致type头字段被忽略，进而typeName为空。

修复方案 #

方案1：给生产者加AMQP消息头的type字段 #

如果能控制生产者，发送消息时在AMQP的消息属性Headers里加type键，值用你自定义序列化器能识别的标识（比如约定好的事件名"OrderCreatedEvent"）。
示例（原生RabbitMQ客户端代码）：

var properties = channel.CreateBasicProperties();
properties.Headers = new Dictionary<string, object>
{
    { "type", "OrderCreatedEvent" }
};
channel.BasicPublish(exchangeName, routingKey, properties, messageBody);

方案2：改自定义序列化逻辑，从消息体读类型标识 #

如果生产者没法改，只能从消息体里取类型信息，就得自定义IJsonSerializer，在反序列化前先解析消息体拿到type值，再传给ITypeNameSerializer。
步骤：

1. 写一个继承自EasyNetQ默认JsonSerializer的自定义类，重写反序列化方法，先读消息体里的type属性；
2. 把这个自定义JsonSerializer注册到EasyNetQ容器：

var bus = RabbitHutch.CreateBus("your-rabbitmq-connection-string", config =>
{
    config.Register<IJsonSerializer, CustomBodyTypeJsonSerializer>();
    config.Register<ITypeNameSerializer, AcceptedTypeNameSerializer>();
});

（注：EasyNetQ 6.x默认用Newtonsoft.Json，自定义时基于这个框架处理即可）

方案3：修正自定义序列化器的注册逻辑 #

确保AcceptedTypeNameSerializer是注册到EasyNetQ的内部容器，而不是只在ASP.NET Core的DI里注册。比如在你的ApplicationModule里：

public override void ConfigureServices(ServiceConfigurationContext context)
{
    var connStr = context.Services.GetConfiguration()["RabbitMQ:ConnectionString"];
    var rabbitBus = RabbitHutch.CreateBus(connStr, config =>
    {
        // 替换EasyNetQ内部的ITypeNameSerializer实现
        config.Register<ITypeNameSerializer, AcceptedTypeNameSerializer>();
        // 其他RabbitMQ配置...
    });
    context.Services.AddSingleton(rabbitBus);
}

方案4：统一EasyNetQ生产者消费者的类型约定 #

如果是EasyNetQ之间的通信，确保生产者发送的CLR类型和消费者端的类型全名（包括程序集名称）完全一致，这样默认的ITypeNameSerializer就能自动映射，不用自定义也能正常解析。

内容的提问来源于stack exchange，提问作者Tempuslight