I have been working on a system which I’m using protobuf-net (version 2.0.0.480) for serializing messages. This application uses a CQRS approach in which commands and events have been separated into different namespaces [and assemblies].
The code will dynamically add the types at runtime for any class that inherits from MessageBase. This is done using the code below:
// Used as a unique reference for each type in a member
private static int _sequence = 1000;
public static void RegisterAll()
{
RegisterAllDerivedFrom<MessageBase>();
}
public static void RegisterAllDerivedFrom<T>(params Assembly[] assemblies)
{
if (assemblies == null || assemblies.Length == 0)
{
assemblies = AppDomain.CurrentDomain.GetAssemblies();
}
var type = typeof(T);
var model = RuntimeTypeModel.Default;
var metaModel = model.Add(type, true);
RegisterAllBaseTypes(type, metaModel, model, assemblies);
}
private static void RegisterAllBaseTypes(Type type, MetaType metaModel, RuntimeTypeModel model, params Assembly[] assemblies)
{
foreach (var t in assemblies.SelectMany(a => a.GetTypes().Where(t => t.BaseType != null && t.BaseType == type)))
{
var subModel = model.Add(t, true);
metaModel.AddSubType(_sequence, t);
_sequence++;
RegisterAllBaseTypes(t, subModel, model, assemblies);
}
}
A few types are added manually to the Default RuntimeTypeModel as well:
RuntimeTypeModel.Default.Add(typeof(ReferenceNumber), true)
.AddSubType(100, typeof(Product))
.AddSubType(110, typeof(ProductGroup));
All the above seems to work fine when all messages were in:
LogicalGrouping.Events
The project moved forward and a new namespace was added:
ReferenceGrouping.Commands
Once ReferenceGrouping.Commands is added and attempts to send a message a ProtoException is thrown. The only workaround that I found for this behaviour is to add the Commands from ReferenceGrouping.Commands into LogicalGrouping.Events.
Is this the anticipated behaviour or should the RuntimeTypeModel be able to support classes being added from completely different namespaces?
Protobuf-net, as per my comment, simply does not care about namespaces, type names or member-names, since it uses numeric keys as identifiers (in accordance with the protobuf spec). This means you can deserialize on a completely different model in dfferent assemblies, as long as the numbers make sense.
Looking at the code, I strongly suspect the problem is that you don’t have reliable (repeatable) sub-type identifiers. If you have, when serializing:
Then it is vitally important, when configuring the models for deserialization, keys that are compatible; for example you could deserialize into:
My guess is that your mechanism for adding sub-types is not ensuring the numbers match. It needs some clue. Actually, looking at your code I wonder if it could also break currently if:
My advice would be: keep an external registration somewhere of what each key means in terms of sub-types. Or: do the same in code using ProtoIncludeAttribute.