Don't register all interfaces on IHandleMessages<T> implementors as scoped in IOC container

[ArveSystad]

Describe the suggested improvement

Is your improvement related to a problem? Please describe.

Consider this example class:

public class OrderQueriers : IHandleMessages<OrderDispatched>, IOrderQueries, IEventHandler<SomeDomainEvent>
{
	private readonly OrderDataContext _dataContext;

	public OrderQueries(OrderDataContext dataContext) 
	{
		_dataContext = dataContext;
	}

	public async Task Handle(OrderDispatched message, IMessageHandlerContext context) 
	{
		var order = _dataContext.Orders.First(x => x.Id = message.OrderId);
		order.Status = OrderStatus.Dispatched;
	}

	public async Task<Order> GetOrder(Guid orderId) 
	{
		return _dataContext.Orders.First(x => x.Id = orderId);
	}

	public async Task HandleEvent(SomeDomainEvent domainEvent) 
	{
		throw new NotImplementedException();
	}
}

I like having some of my classes implement several interfaces, to easily keep related things together, instead of having to abstract it out into other classes for no good reason. Typically for read models/projections in CQRS and/or Event sourced environments, I can end up having many implemented interfaces like this. When NSB detects the IHandleMessages<> below, it registers the following in the service collection at startup:

• OrderQueries: Scoped
• IHandleMessages<OrderDispatched>: Scoped
• IOrderQueries: Scoped
• IEventHandler<SomeDomainEvent>: Scoped

While, in my running app, I'd like it to be

• IHandleMessages<OrderDispatched>: Scoped
• IOrderQueries: Transient
• IEventHandler<SomeDomainEvent>: Transient

Describe the suggested solution

On startup, while scanning for IHandleMessages<T>, only register the NServiceBus handlers - ignore other interface implementations on the same class, and don't register the class itself as a service either.

This would make several things easier:

• When setting up containers for unit tests, it's easier to get them to behave more like "the real deal"
• Explicit control over my own things: I know exactly what will be used if I depend on my own things
• You'll avoid various instances of "Cannot resolve scoped service 'Foo' from root provider"

I guess this'd be a potentially breaking change for some, though. But it would be very, very neat. 🚀

Describe alternatives you've considered

A workaround now is to clean up your own container on startup, but this quickly gets messy.

Additional Context

Nugets installed while discovering this:

NServiceBus.Extensions.Hosting 2.0.0
NServiceBus 8.1.4

[andreasohlund]

Thanks for the suggestion @ArveSystad , like you say this is tricky from a backwards compatibility perspective. Scope is locked at this stage for this upcoming v9 but we'll see if anything can be done once that is out