We have an old application that was written against NServiceBus 3 and I am upgrading it to NServiceBus 8. One of the main issues I am having is updating a custom transport that was written. The transport itself inherits from TransactionalTransport and implements IManageMessageFailure.
Looking through the documentation I can see that in NServiceBus 4 TransactionalTransport was changed to TransportReceiver but that is about all of the information I can find.
Is there any recent documentation on how to write custom transports? Any information on this would be greatly appreciated.
Unfortunately, that’s going to be pretty difficult. To upgrade a custom transport from NServiceBus 3 to 8, you’re basically throwing away all your code and starting over from first principles.
I am curious what message queue system this transport is targeting?
We don’t really have any documentation on how to write a custom transport because we don’t believe that’s something the average user, or even the expert user, should really attempt. The transport manages the whole message pump for that broker, and there are a lot of concerns a transport must handle related to that. It’s far from implementing how to get a message and how to ACK/NACK a message.
The closest thing we have to documentation is to look at the source code for a “similar” transport.
IIRC, NServiceBus 3 supported only MSMQ. Nowadays we support a whole bunch. My best advice would be that except in some absolutely exceptional circumstance, it’s going to generally be a better ROI to pick one of the supported transports and migrate to it rather than try to reimplement a bespoke transport from scratch and then support that yourself long term.
But if you tell me what broker you’re targeting, I can log that internally. We obviously only want to build transports that people will actually use, so keeping track of interest in other queueing tech is essential.
Our system uses SQL Server Service Broker, and the existing transport takes messages from there. We want to leave the part of the system that puts messages into Service Broker alone so the main task is updating the transport that pulls the messages out of Service Broker.
The SQL Server Transport might be close enough to use as a good reference for getting what we need in.