This sample is based on the PubSub sample so if you haven't gone through it yet, it is recommended to start there, and only after that sample is understood, to come back to this sample.

In this sample, there are two message projects - V1.Messages and V2.Messages.

namespace V1.Messages
{
    public interface SomethingHappened : IMessage
    {
        int SomeData { get; set; }
    }
}

And the version 2 message schema inherits from the version 1 schema as shown below, adding another property on top of the properties in the version 1 schema.

namespace V2.Messages
{
    public interface SomethingHappened : 
                    V1.Messages.SomethingHappened
    {
        string MoreInfo { get; set; }
    }
}

There are two subscribers as before, but now one subscriber is subscribed to the version 1 message schema - V1Subscriber, and the other subscriber is subscribed to the version 2 message schema - V2Subscriber.

Notice that both of the subscribers both have an EndpointConfig file that inherits IConfigureThisEndpoint, AsA_Server. Subscribers have a message handler for the messages from their respective versions. Yet, there is a slight difference in their config files.

V1Subscriber has the following in its UnicastBusConfig:
 

<UnicastBusConfig>
  <MessageEndpointMappings>
    <add Messages="V1.Messages" Endpoint="V2PublisherInputQueue" />
  </MessageEndpointMappings>
</UnicastBusConfig>

While V2Subscriber has this in its UnicastBusConfig:

<UnicastBusConfig>
  <MessageEndpointMappings>
    <add Messages="V2.Messages" Endpoint="V2PublisherInputQueue" />
  </MessageEndpointMappings>
</UnicastBusConfig>

The only difference is that each subscriber is mapping the version of the schema on which it is dependent.

Now let's look at V2Publisher, which is very similar to the publisher from the PubSub sample. The only thing that the V2Publisher is doing is publishing a message from the version 2 schema. However, when we run the sample, we'll see that the V1Subscriber receives these messages as well:

Notice that when each subscriber processes the event, each sees it as the schema version it is compiled against. In this manner, publishers can be extended from one version to the next without breaking existing subscribers, allowing new subscribers to be created handling the additional information in the new version of the events.