Binary Deserialization with different assembly version

Question

I have a project which uses BinaryFormatter to serialize a collection of structs with string and bool? datatypes.

The serialization/deserialization works fine, however if I were to change the assembly which does the work it fails to deserialize because of the header in the binary file indicating that it requires Assembly x instead of Assembly y to handle the data.

Is it possible to setup the serialization/deserialization to be assembly agnostic?

Felicitation

I'm having the same problem... glad to know it's been addressed. – Benita

Answer 1

You can control how the binary formatter resolves its types by assigning a custom SerializationBinder to the formatter. In this way, you won't need to mess with the AppDomain's resolve events and you eliminate the risk of unexpected side effects from that.

There is a detailed example at MSDN.

Errata

Thanks, this seems like the safest option - especially if I move the code into a different assembly... – Felicitation

@mmr: I just tested it and got it working. Start out with the MSDN example in the answer, and modify the serialization binder to allow some assembly version mismatch. – Errata

One thing you'll need to be aware of is that if you have nested types (e.g. a custom collection of custom objects) you'll need to be loading multiple assemblies... try stepping through the overloaded BindToType method. – Felicitation

How about going the other way? When you want to control how the assemblies that are in the binary WHEN SERIALIAZING? – Zoezoeller

Answer 2

You can change your BinaryFormatter property AssemblyFormat to make serialization independent of assembly version.

// Example
var binFormat = new BinaryFormatter();
binFormat.AssemblyFormat = System.Runtime.Serialization.Formatters.FormatterAssemblyStyle.Simple;

Capita

It works but data should be serialized and deserialized using the same method. – Rebuttal

Answer 3

Hook into the AppDomain.OnAssemblyResolve event and fix-up the assembly names

private System.Reflection.Assembly OnAssemblyResolve( System.Object sender, System.ResolveEventArgs reArgs )
{
     foreach( System.Reflection.Assembly assembly in System.AppDomain.CurrentDomain.GetAssemblies() ) 
     {
         System.Reflection.AssemblyName assemblyName = assembly.GetName();
         if( assemblyName.FullName == reArgs.Name ) 
         {
              return( assembly );
         }
     }
}

source: http://osdir.com/ml/windows.devel.dotnet.clr/2003-12/msg00441.html

Macrogamete

I was originally going to use this, however I can see that there's possible corner cases of failing badly with concurrent execution.. – Felicitation

Answer 4

There are altenative (binary) serialization engines (like this) that aren't assembly dependent.

Orator

Answer 5

The GAC is your first resource, allowing different versions of the assembly to co-exist side-by-side. But that doesn't really solve anything unless your app is version tolerant too. Binary serialization has several features to handle version tolerant serialization. Read about it in this MSDN library article.

Electroacoustics

Thanks for the GAC suggestion, however I'm trying not to leave a heavy footprint with the App, having everything run from its own folder. – Felicitation