As I've been doing a bit of work on remoting (see my previous blog post) I'm necessarily looking quite a bit into the serialization of messages. Yesterday I found quite a good article on the CodeProject website with a good set of references about remoting it's well worth a read. While I'm on the subject I thought I'd share my variation of Ingo Rammer's RemotingHelper class. This is a class that enables you to create remote classes based on interfaces via the remoting configuration file. Normally you would have to use a call to Activator.GetObject() and that takes URL so suddenly all of your configuration has to be done outside the easy to edit config file. The only issues I had with the Ingo's RemotingHelper class was that it was very fussy over the type of the remoting object so if the version changed it would stop working. To rectify that issue for my case I only store the FullName in the lookup table. This makes it a lot easier when getting auto-versioned builds from our build system (we have two build computers, one called Bob and the other called Wendy - guess why) so I don't have to change both the client and server every single time.

/// <summary>
/// Use Interface-based remote objects with config files
/// http://www.thinktecture.com/resourcearchive
///               /net-remoting-faq/useinterfaceswithconfigfiles
/// </summary>
public class RemotingHelper
{
    private static bool m_IsInit;
    private static Dictionary<string, WellKnownClientTypeEntry> m_WellKnownTypes;

    /// <summary>
    /// Replacement to Activator.GetObject which allows config files
    /// to work properly
    /// </summary>
    /// <param name="type">Type to create</param>
    /// <returns>Type created</returns>
    public static Object GetObject(Type type)
    {
        if (!m_IsInit)
        {
            InitTypeCache();
        }

        WellKnownClientTypeEntry entr;

        if (!m_WellKnownTypes.TryGetValue(type.FullName, out entr))
        {
            throw new RemotingException("Type not found!");
        }

        return Activator.GetObject(entr.ObjectType, entr.ObjectUrl);
    }

    private static void InitTypeCache()
    {
        m_IsInit = true;
        m_WellKnownTypes = new Dictionary<string, WellKnownClientTypeEntry>();
        foreach (WellKnownClientTypeEntry entr in
            RemotingConfiguration.GetRegisteredWellKnownClientTypes())
        {

            if (entr.ObjectType == null)
            {
                throw new RemotingException("A configured type could not " +
                  "be found. Please check spelling");
            }
            m_WellKnownTypes.Add(entr.ObjectType.FullName, entr);
        }
    }
}

This only really works because the FullName is likely to be pretty unique and will change a lot less often than the Type information which changes every build due to the version increments.

 The actual purpose of this blog at the start was to mention a lovely little thing I stumbled across while looking for solutions to the Shared version mismatch remoting calls was to do with serializing classes for persistence. Again if you serialize something to disk it's all good you can load it up again no problems. Unless the version of your strongly named assembly changes version at which point suddenly it stops working. The simple solution that seems to work is....

            BinaryFormatter formatter = new BinaryFormatter();
            formatter.AssemblyFormat = FormatterAssemblyStyle.Simple;

 Now when deserializing the runtime now no longer has to find the perfect match for the assembly - just something that is 'close enough' will do - lovely jubbly.