Suggestion: Place common interfaces in separate abstractions assembly

Apologies if this has been suggested before (search didn’t reveil it if it has) but I’d like to suggest putting some of the common interfaces (most notably IMessage, ICommand and IEvent) into a separate assembly like Microsoft does.

We like to create supporting class libraries with various functions that often rely on most notably the IEvent type which now have to take a dependency on the entire NServiceBus package (or use unobtrusive mode, but we prefer to just keep using the default interfaces).

It seems to me that it shouldn’t be a big change to introduce in a future version and I see only benefits. Is there a particular reason this hasn’t been done yet?

Hi Robert,

I don’t know the whole scope of your scenario, but have you seen message conventions documentation? Would that solve the problem of the dependency on IEvent? There’s also a sample project you can download and try.

Hi Robert

We actually had such an interface assembly in the past

This is the original issue that explained some of the decision making around deprecating the interface assembly

Unfortunately I don’t have all the context to give you a better answer. But now looking at the issue I’m wondering why we haven’t considered setting a fixed version on the NServiceBus.Interfaces assembly (like 1.0.0) and leave it as long as we can on that version. That would have addressed your concern.

That being said nothing prevents you today to do exactly that with conventions

Maybe @andreasohlund has some more historic knowledge and can chime in here

Regards
Daniel

The thinking back then was that the NServiceBus package:

  • no longer had any public dependencies
  • no longer was big in size
  • assembly version to {major}.0.0 to not cause assembly redirect issues

the benefits of a separate NSeriviceBus.Interfaces packages were no longer there.

The upside I can see at this stage would be if that package was on a separate versioning scheme so that it could support multiple major versions of NServiceBus allowing assemblies only containing messages and message handlers to target more major versions of NServiceBus.

From an internal perspective, I can see this helping us to ship major versions of NServiceBus more frequently.

I’m curious if you see more upsides from a user perspective Robert?

Cheers,

Andreas

A very easy alternative is to just create your own set of marker interfaces and put these in a lib. This also makes your message types not requiring any NServiceBus dependancy. For example, I did this in the past using attributes instead of marker interfaces:

– Ramon

Or you can use my little AttibuteConventions library, for more information: https://milestone.topics.it/2019/06/19/i-built-a-thing-well-two.html