MassTransit发送含接口属性命令时子类属性丢失问题求助

我之前也碰到过一模一样的问题，核心原因是MassTransit默认的序列化逻辑不会为接口类型的属性保留多态类型信息，再加上你用匿名类发送命令的方式，进一步导致接收端反序列化时只能识别到IDocument接口定义的成员，无法还原InventoryList的子类属性。下面是具体的解决步骤：

1. 停止使用匿名类发送命令，改用具体的命令实现类 #

你当前用匿名类构造ICreateDocumentCommand的方式，会让MassTransit无法正确关联命令的具体类型信息。换成CreateDocumentCommand实例发送：

await endPoint.Send<ICreateDocumentCommand>(new CreateDocumentCommand { 
    CorrelationId = // 外部传入值
    SocketId = // 外部传入值
    UserName = // 外部传入值
    UserId = // 外部传入值
    Document = // 外部传入的InventoryList实例
});

这样MassTransit能明确识别命令的具体类型，为后续序列化提供更准确的元数据。

2. 配置序列化器，启用多态类型信息保留 #

MassTransit默认的JSON序列化器（不管是Newtonsoft.Json还是System.Text.Json）默认不会在序列化接口类型时添加类型标识，接收端也就不知道要反序列化为InventoryList。我们需要手动启用类型名称处理：

如果你用Newtonsoft.Json（MassTransit旧版本默认） #

在Bus配置中添加序列化器配置：

services.AddMassTransit(x =>
{
    // 注册你的消费者、命令定义等...

    x.UsingRabbitMq((context, cfg) =>
    {
        // 启用NewtonsoftJson序列化并配置类型名称处理
        cfg.UseNewtonsoftJsonSerializer(options =>
        {
            // Auto模式会在多态场景自动添加$type字段
            options.TypeNameHandling = TypeNameHandling.Auto;
        });

        // 其他RabbitMQ配置（如主机地址、队列等）
        cfg.Host("rabbitmq://localhost");
        cfg.ConfigureEndpoints(context);
    });
});

如果你用System.Text.Json（MassTransit新版本推荐） #

配置System.Text.Json的多态支持：

services.AddMassTransit(x =>
{
    // 注册你的消费者、命令定义等...

    x.UsingRabbitMq((context, cfg) =>
    {
        cfg.UseSystemTextJsonSerializer(options =>
        {
            options.IncludeFields = true;
            options.TypeInfoResolverChain.Insert(0, 
                new JsonPolymorphicTypeResolver()
                {
                    // 为IDocument添加已知的派生类型
                    DerivedTypes =
                    {
                        typeof(Document),
                        typeof(InventoryList)
                    }
                });
        });

        // 其他RabbitMQ配置
        cfg.Host("rabbitmq://localhost");
        cfg.ConfigureEndpoints(context);
    });
});

3. 确保两端类型一致 #

发送端和接收端的IDocument、Document、InventoryList类必须完全一致：

• 命名空间相同（你已经满足，都在Common.Models下）
• 属性名称、类型完全匹配
• 无序列化/反序列化的特性冲突

这样接收端才能通过序列化器添加的类型标识，正确将数据反序列化为InventoryList实例，而不是动态生成的GreenPipes.DynamicInternal.Common.Models.IDocument代理对象。

验证效果 #

完成上述配置后，发送的消息体中会包含类似"$type": "Common.Models.InventoryList, Common.Models"的类型标识，接收端就能据此正确还原WarehouseId等子类属性了。

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