Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
The NSB interfaces dll was created to allow people to have a smaller dependency when creating a messages assembly. With the introduction of unobtrusive messages that is no longer required. As such
How the NServiceBus.Interfaces nuget will be deprecated
When V5 is release a stub nuget for NServiceBus.Interfaces will be released. Located here https://www.nuget.org/packages/NServiceBus.Interfaces/126.96.36.199
This nuget has a
For all of the below scenarios result in v5 of
On a project with no NSB
Install NServiceBus.Interfaces v5
Install NServiceBus v5
On a project with an earlier version of NSB
Is this implying that if we have something built with v5.0 and it subscribes to messages using the unobtrusive messages, it will continue to work with all version upgrades to NSB on the publisher side? Will the "subscription protocol" be guaranteed to work or be versioned appropriately?
And is the suggestion to use unobtrusive specifically? The reason I ask, is because It is nice that the author of the messages is strongly suggesting for example that when I publish an event, it is just that an event. If the consumer of the event has to explicitly "convert" it to a command to be able to use it in a subsequent Bus().Send().
I kinda agree with this change. I think there are better conventions you can use than interface decoration for defining events and commands.
That being said, this is only an issue in NSB because the interfaces package is versioned at the same rate as the rest of the framework. I don't think this should have been the case. As these are really only used for decoration I don't think its really necessary the interfaces have a version greater than semver 1.*, ie i don't think theres ever been an actual breaking change to the interfaces themselves. All NSB versions then would use the same major version of the interfaces which would remove this issue completely.