wsdl.exe / svcutil.exe - есть ли способ не создавать классы для типов в xsds во время создания веб-службы или клиента

Question

У нас есть централизованно управляемая объектная модель для типов в схеме в C #. Мы хотим, чтобы все на предприятии использовали эту объектную модель вместо того, чтобы использовать модель, сгенерированную каждый раз из wsdl / svcutil во время реализации клиента веб-сервиса или сервиса.

есть ли параметр (любой другой способ), чтобы wsdl / svcutil не генерировал классы для типов схем во время их выполнения?

Answer 1

Я не знаю какой-либо конкретной настройки или параметра командной строки для обеспечения этого - что вы можете сделать, но это в основном вопрос обучения и применения путем проверки, это совместное использование библиотеки классов (сборка, в DLL) ) с разработчиками и убедитесь, что все ссылаются на эту общую библиотеку классов и оставляют настройки по умолчанию только в диалоговом окне «Добавить ссылку на службу» (на странице «Дополнительно»):

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

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

Answer 2

Я считаю, что вы ищете: svcutil.exe /r your-dtos.dll

/ ссылка: - Типы ссылок в указанном сборка. При создании клиентов используйте эта опция для указания сборок, которые может содержать типы, представляющие импортируемые метаданные. (Короткий: / Г)

На мой взгляд, серьезная ошибка в дизайне - тесная связь прокси-сервера WCF, канала конечной точки, операций службы и полезных нагрузок dto с одним и тем же сгенерированным клиентским прокси-сервером.

Это то, что подтолкнуло меня к решению в моей открытой структуре веб-сервисов , где я разделяю конечную точку и полезную нагрузку, которая позволяет:

• Тот же клиент веб-службы (т. Е. Soap11, Soap12, XML, JSON) для возможности вызова любого веб-службы.
• Позволяет мне использовать один и тот же экземпляр DataContract dto в любом клиенте веб-службы
• Это имеет много преимуществ, в том числе возможность предоставления одной и той же веб-службы на нескольких различных конечных точках без какой-либо дополнительной настройки. Таким образом, предоставляя оптимизированные конечные точки веб-сервиса для каждого потребителя моего сервиса. Например.
  • XML для совместимости и клиентов строго типа,
  • JSON для клиентов Ajax,
  • WSDL для сред, которые предпочитают сгенерированный код (например, Flex Builder, VS.NET «Добавить ссылку на службу» и т. Д.)

В моей компании мы разработали сотни веб-сервисов, вызываемых рядом различных клиентов, таких как Ajax, Flash / ActionScript, C ++, Silverlight, ASP.NET, и возможность вызова одного и того же веб-сервиса через разные конечные точки спасли нас бесчисленное множество ч.

Answer 3

Если вы удалите конечную точку mex из файла конфигурации службы, клиентское приложение не сможет обнаружить и сгенерировать прокси-объекты.

Чтобы справиться с этой ситуацией, если я правильно понимаю ваш вопрос, выполните следующие действия:

1. Создайте общий набор библиотек DLL, в которых есть служба, и контракты данных / общая объектная модель.
2. Создайте сервис, используя контракты в общей dll вместо контрактов, которые Visual Studio создает при создании нового сервиса.
3. Удалите конечную точку MEX из файла конфигурации сервера (это существенно нарушит генерацию прокси).
4. Пусть ваш клиент использует общую dll и вручную создает каналы на стороне клиента (через фабрику каналов и т. Д.).

В этом подходе вы вообще не используете wsdl.exe / svcutil.exe, так как вы по сути обходите wsdl. Вы также не добавляете сервисные ссылки, так как вручную управляете соединениями.

РЕДАКТИРОВАТЬ: Следуя этому подходу, клиент все еще может попытаться сгенерировать прокси-объекты через wsdl.exe / svcutil.exe, но они не получат правильную информацию от wsdl. По сути, они генерируют неработающий / неполный прокси.