NServiceBus PubSub - how to break binary dependencies between pub'r and sub'r?

0
votes

I have a requirement to build a NSB subscriber which will subscribe to messages being published by a service which is already live. This service was built with a messages assembly containing the NSB IMessage implementations which I want to subscribe to. So to build my subscriber I need a hard dependency on this assembly.

When my subscriber starts up it sends some messages to the publisher input queue which results in the publisher recording my subscriptions in the database. One of my subscriptions looks like this:

MyNamespace.MyMessageType, MyNamespace, Version=1.0.0.0, Culture=neutral, PublicKeyToken=MyPublicKeyToken

Unfortunately the publisher is publishing messages from an assembly which is not strong named. So when publishing, the subscription evaluation process fails to evaluate successfully against my subscription, because the public key token of the message being published (value = null) does not match my subscription.

My question is: Can I not subscribe to messages by Type and version only? Even better - can I not subscribe to messages based on some external contract (like an XSD) and break this dependency altogether?

Many thanks in advance.

UPDATE: The NSB docs hint at something like this here:

http://www.nservicebus.com/MessagesAsInterfaces.aspx

1
nservicebuspublish-subscribe
Is there a strong business case why the messages assembly must be strong-named? – David Boike
Well, not a business case, but in general it is safer to go into a production environment with strong named code. If this dependency was third party (it's not) then I would have a real problem because I would have no idea if the assembly came from a trusted source or not. I know what you are saying though. In actual fact I am not blocked by this because I have asked the team developing the messages to simply sign the messages assembly. But my post is still valid. When using NSB pubsub you will always have a hard dependency on your publisher which doesn't exist if you are just using Bus.Send(). – tom redfern

1 Answers

1
votes

For regular messages you create you can use the XsdGenerator tool in the tools directory of NSB to generate a schema that you can pass along to other endpoints. You will want to use this tool instead of the .NET Framework tool as it does not support interfaces. From there you can use the schema to handle messages.

For subscription messages, if you don't want to use the assembly you could tell NSB to DoNotAutoSubscribe() and subscribe manually(Bus.Subscribe(Type)) passing along the Type of the message however you wish. This could be off the schema or some other configuration.