Apologies in advance as I know there are posts on the migration necessary from IBus to IMessageSession and IMessageHandlerContext and some of the decisions leading to the separation of these interfaces.
Background, we have a well established mature system built on NSB v5.x, we have numerous logical services and components shared across self-hosted endpoints (i.e. ASP.NET, WebAPI etc.) and NSB hosted handlers. We typically injected ISendOnlyBus into these logical services and shared components where there is a need for them to send bus messages.
Migrating all of these numerous shared services and components away from ISendOnlyBus to is not without considerable effort. Whilst I’ve read some of the decisions for deprecating IBus I am wondering if the true extent of this change on customer implementations was realised.
Ultimately it does mean a lot of refactoring and I’m not clear on the effects or the behaviour of shared components, services and libraries which previously used ISendOnlyBus or IBus as it seems such code now needs to know the context in which it is being called/used (i.e. directly from a handler or outside of a handler - self-hosted).
Apologies if I’ve misunderstood but it does seem like the established shared code, services, components etc. can no longer be truly shared and must be separated to accommodate IMessageSession and IMessageHandlerContext.
There certainly seems to be a point being made of not blindly converting IBus references to IMessageSession as its not a safe operation.
I came across the unified sessions extension which looks like it could be used in our scenario for migration purposes. But what I haven’t found yet is a recommended or definitive long term approach to utilising these separate interfaces and the implications from an overall system design perspective.
Any suggestions, general advice or migration lessons would be appreciated.