Configuration 我升级到MassTransit 5.2.0，现有代码正在抱怨LoadFrom现已过时。

警告确实建议阅读文档，但当前文档建议在配置需要DI支持的使用者时使用LoadFrom。当前正在使用.net核心依赖项注入。找不到允许DI的使用者方法

这一点继续有效。只是让我在前进中感到紧张

cfg.ReceiveEndpoint(host, "adjudication-api", e => 
{
   e.PrefetchCount = 16;

   e.UseMessageRetry(x => x.Interval(2, 100));

   e.LoadFrom(provider);

 });

---

如果您能提供指导，我们将不胜感激。

虽然我们仍然支持使用

LoadFrom

，但我们不鼓励使用它，因为它实际上会助长一种非常糟糕的做法，将所有鸡蛋放在一个篮子里。我经常遇到开发人员，他们在一个队列中有几十个消费者，他们都是无关的。将使用者分布在多个队列中以避免瓶颈、分离代理上的流量以及更好地了解系统是很重要的

<> >而不是使用<代码> LoadFrom < /代码>，请考虑下面的方法：

cfg.ReceiveEndpoint(host, "adjudication-api", e => 
{
   e.PrefetchCount = 16;

   e.UseMessageRetry(x => x.Interval(2, 100));

   e.Consumer<AdjudicationConsumer>(provider);
 });

cfg.ReceiveEndpoint（主机，“裁决api”，e=>
{
e、 预取计数=16；
e、 UseMessageRetry（x=>x.Interval（2100））；
e、 消费者（提供者）；
});

然后，如果您有另一个处理报销的消费者，请为其创建一个单独的端点：

cfg.ReceiveEndpoint(host, "reimbursement-api", e => 
{
   e.PrefetchCount = 16;

   e.UseMessageRetry(x => x.Interval(2, 100));

   e.Consumer<ReimbursementConsumer>(provider);
 });

cfg.ReceiveEndpoint（主机，“报销api”，e=>
{
e、 预取计数=16；
e、 UseMessageRetry（x=>x.Interval（2100））；
e、 消费者（提供者）；
});

---

使用这种方法，消费者分布在多个队列（接收端点）。

我不同意许多消费者认为一个队列是“非常糟糕”的做法。在许多情况下，这是有意义的——例如，如果（a）我的应用程序希望消费者被同一并发限制器或断路器实例选通，或者（b）我的应用程序很简单，但希望通过DI发现消费者。通过

obsoletattribute

进行弃用是一种过于草率的笼统判断。它打破了我们这些在CI环境中使用警告作为错误的人。好吧，这是一个警告，如果你认为你做的是正确的，你可以把它说出来。从支持的角度来看，我花了太多时间回答有关为什么每个消费者都在每个队列中等问题。特别是当更多的人盲目地将消费者托管在与ASP.NET核心网站相同的过程中，而不了解这样做的服务生命周期方面时。很公平，在我的两个案例中，我都用了

#pragma

。谢谢Chris，这是否意味着autofac现在是在我们的消费者中获得DI支持的必要条件？e、 消费者（提供者）在运行时为我的.net core DI实现服务。例如，此示例：