Вызов службы WCF без генерации сборки

Question

Я пытаюсь написать код на C#, который будет называть службу WCF «на лету», импортируя WSDL, исследуя его, а затем динамически вызывает вызовы.

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

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

Изложенные здесь: Creating an assembly on the fly from a WSDL

Я хотел бы избежать образования сборки, а затем размышляя над ним, если это возможно.

Я просмотрел код динамического прокси в ссылке, и они используют класс framework для импорта. Этот класс является WsdlImporter. Поэтому я подумал, что я могу использовать это и изучить схему WSDL и определить, какие вызовы присутствуют и какие входы и выходы доступны.

Проблема в том, что информация о типе отсутствует в объектах MessagePartDescription, которые создает WsdlImporter. По-видимому, этого не хватает because it cannot find the types yet - see the response to the question from Brian.

Значит, любой совет о том, как я должен действовать? Неужели я полностью ошибаюсь?

Answer 1

Это, вероятно, не ответ, но я отправлю его как один, чтобы полностью описать мое мнение.

Динамический прокси:
ИМО это пример неправильного использования технологии. Это элементарное поведение WSDL - если оно меняется, вам нужно изменить клиента, или вам нужно сделать правильное WSDL-управление версиями и создать новый клиент.

Вы все еще должны как-то сказать, что ваш клиент получит WSDL - означает ли это, что вы будете разбирать WSDL перед каждым звонком? Не кажется хорошей идеей.

Информация о типах действительно не является частью WSDL, поскольку по умолчанию WSDL генерируется как совместимый. Типы CLR не требуются для взаимодействия. Когда вы создаете прокси-сервер службы путем добавления ссылки службы или Svcutil, он будет генерировать код для типов, определенных в WSDL. Затем этот код необходимо скомпилировать.

Вы можете использовать NetDataContractSerializer вместо DataContractSerializer. NetDataContractSerializer добавляет информацию типа CLR в WSDL, но я все еще ожидаю, что новые типы должны быть известны вашим клиентам - это означает развертывание новой сборки с использованием типов и ее использование клиентами. Это почти похоже на тот же подход, когда просто развертывание сборки с новым статическим клиентским прокси.

Динамические WF клиент
Я также не вижу слишком много использования этой архитектуры - вам все еще нужен изменить клиент, чтобы отразить новые шаги WF, не так ли?

Изменение WF
Мы говорим о фундаменте Windows Workflow? Я не могу себе представить сценарий, в котором вы создаете WF, выставляете его как сервис и затем меняете его. Когда вы открываете WF в качестве сервиса, вы, вероятно, определяете длительный WF. Долгосрочные WF используют стойкость, основанную на сериализации (по крайней мере, в WF 3.5, но я считаю, что она такая же в WF 4).Когда вы изменяете определение WF, все сохраненные WF, скорее всего, обречены, потому что они никогда не будут deserialize. Эта ситуация обычно решается путем параллельного развертывания новой и старой версии, где старая версия используется только для завершения неполных WF. Опять же это новые клиенты.

Answer 2

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

WCF имеет механизм для этого IExtensibleDataContracts см: http://msdn.microsoft.com/en-us/library/ms731083%28v=VS.100%29.aspx

Лучшие практики для управления версиями контрактов могут быть найдены here