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?
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.
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
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?
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:
Apologies, I had completely overlooked that there were actually some responses to my request.
Our situation is such that we have several packages that contain base functionalities that involve events or event handlers. Right now these always need to reference the entire NServiceBus package (and thus need to be kept up to date) just to use the IEvent, ICommand or IHandleMessages<> interfaces.
Microsoft seems to have discovered this as well and introduced the .Abstractions packages that are extremely lightweight and thus perfect to use as dependencies of your own packages. It just occurred to me that there are very few downsides to creating a NServiceBus.Abstractions package with just the interfaces (which I suppose could be kept at version 1 for a very long time)
Of course one can create own interfaces and use the Unobtrusive mode, but it feels silly to create my own IEvent and ICommand interfaces (how would we even name those to make clear they are the ones that should be used) when there are perfectly good interfaces available.