Custom serialization across AppDomain

Question

Short version: I'm trying to customize serialization across an AppDomain boundry, specifically to handle cases where each side of the AppDomain has a slightly different version of the class. How do I do this?

Long version: We're using AppDomains to manage different submodules underneath the larger application. We want to deploy these submodules independently, hence the use of AppDomains. We have a shared contracts dll between the main application and the submodules, different versions of the contracts dll can end up in the various submodules as each one gets updated less frequently than the main application. As a result, sometimes a new field or new type gets added in the contracts dll, and is used in the main application, but the submodule does not know how to serialize it.

I think I can fix this issue by customizing the serialization process, specifically SerializationBinder.BindToType. However to do this, I need to tell each side of the AppDomain to use this serialization binder. How do I do this? All of the examples I've seen online have explicit calls to Serialize() and Deserialize(). My code for initializing the AppDomain is:

var appDomainSetup = new AppDomainSetup
{
    ApplicationBase = config.BasePath,
    ShadowCopyFiles = "true",
    ConfigurationFile = File.Exists(configPath) ? configPath : null,
};

AppDomain.CreateDomain("myappdomain", null, appDomainSetup);

Thanks for the assistance on this.

Answer 1

There is a framework for exactly what you want to do. It's in the base class library, it's called MAF (Managed AddIn Framework), and you can use it by referencing System.AddIn.dll.

MAF consists of three concepts:

1. Pipeline
2. Discovery
3. Activation

You define an AddIn pipeline by creating several interfaces and implementing adapters between them. This is a tedious process, but it enables you to do both AddIn-side as well as host-side versioning of your interfaces. You can use old AddIns in a new host, and you can use new AddIns in an older version of the host, given that you deploy appropriate adapters. The whole process is described over here.

Discovery enables your host application to enumerate all AddIns that it finds in your configured locations, including metadata.

Activation then uses any AddInToken found during the discovery phase to activate an AddIn. You can choose between several isolation models, including AppDomains, which should fit your use case pretty well.

I have used the framework in different projects several times. If you get used to the somewhat complex pipeline development process and tripped over several pitfalls (always set "Copy Local" to false for AddInViews references in your AddIns), it pays.

For an extensive tutorial creating a sample application, look here.