У меня есть следующий дизайн для моего клиента / сервера удаленного взаимодействия:
Сборка SharedTypes со строгим именем содержит только интерфейсы. Серверная сборка реализует их. Мой CAO (объект, активированный клиентом) имеет тип Account.
Я применяю шаблон проектирования фабрики для работы с CAO. То есть фабрика (Server), которая работает как объект, активируемый сервером (Singleton), имеет метод CreateAccount, возвращающий новый экземпляр «реального класса» (Account CAO) клиенту. Это дает преимущество в том, что мне не нужно распространять реализацию на клиентскую сборку.
Поскольку версия сборки 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: Извините за длинное объяснение, но подумал, что это поможет полностью описать сценарий, а также обеспечит правильное понимание.