.Net Remoting, управление версиями и CAO

Question

У меня есть следующий дизайн для моего приложения удаленного взаимодействия клиент / сервер:

Сборка со строгим именем SharedTypes содержит только интерфейсы. Серверная сборка реализует их. Мой CAO (объект, активированный клиентом) Account тип.

Я внедряю шаблон проектирования фабрики, чтобы иметь дело с CAO. Т.е. заводской (Server), который работает как объект, активируемый сервером (Singleton), имеет метод CreateAccount возвращая новый экземпляр "реального класса" (Account САО) клиенту. Это дает преимущество в том, что мне не нужно распространять реализацию на клиентскую сборку.

Поскольку версия сборки SharedTypes будет обновляться с течением времени, я хочу убедиться, что она по-прежнему обратно совместима со старыми клиентами, созданными на основе старых версий.

На мой предыдущий вопрос был задан вопрос, почему не возникло исключение при доступе к SAO (объект, активированный сервером), когда клиент был собран со ссылкой на более старую версию общей сборки.

Я обнаружил, что MSDN здесь в разделе "Активированные сервером объекты":

Если информация о версии не указана при настройке службы, при активации объекта используется самая последняя версия сборки. Например, если у вас есть две сборки: MyHello версии 1.0.0.0 и MyHello версии 2.0.0.0, известный объект активируется с использованием сборки версии 2, если информация о версии не указана. Важно отметить, что эта версия используется независимо от версии, на которую ссылался клиент при сборке.

Поэтому кажется, что старые клиенты всегда будут получать последние версии SAO и могут делать вызовы по нему. Однако для САО говорится:

Версия, активированная для клиента, не может быть настроена; версия, на которой был построен клиент, всегда используется.

Для CAO, которые создаются клиентом с использованием нового оператора или Activator.CreateInstance (из Ingo Rammer Advanced .NET Remoting (C# Edition)):

Что делает сервер, когда запрашиваемая версия CAO недоступна, так это получение самой высокой версии указанной сборки. Когда в GAC доступны версии 1.0.1.0 и 2.0.0.1 и запрашивается версия 1.0.0.1, сервер выберет 2.0.0.1 для создания экземпляра запрошенного объекта, даже если они отличаются по основному номеру версии.

Тем не менее, так как я использую шаблон проектирования фабрики, чтобы создать экземпляр Account CAO это, кажется, не применяется, следовательно, System.InvalidCastException: Return argument has an invalid type исключение при попытке получить объект Account с сервера, созданного с использованием более высокой версии SharedTypes, чем у клиента.

Похоже, что для того, чтобы эмулировать стандартное поведение для разрешения версий сборки или для перенаправления на совершенно другую версию, мне нужно использовать запись assemblyBinding в файле конфигурации приложения клиента, например:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name="ServerLib"
             publicKeyToken="2752785e627d5953"
             culture="neutral" />
    <bindingRedirect oldVersion="1.0.0.0"
             newVersion="2.0.0.0" />
  </dependentAssembly>
</assemblyBinding>

или используйте политику перенаправления для перенаправления (поскольку SharedTypes является сборкой со строгим именем).

Является ли это лучшим подходом для управления версиями при работе с CAO, возвращенными с использованием шаблона проектирования фабрики?

PS: Извините за длинное объяснение, но подумал, что это поможет полностью описать сценарий, а также убедиться, что мое понимание верно.