Невозможно создать ShareLibrary с контрактом данных с помощью SVCUTIL

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

Однако за эти годы я узнал, что в целом инструменты, работающие с XSD и привязкой кода, всегда ограничены; Чтобы обойти эти ограничения, решение состоит в том, чтобы начать с тщательного планирования содержимого XSD и того, как WSDL должны использовать это содержимое. Будет проще, если я буду контролировать процесс генерации WSDL и XSD; когда я «наследую» или «перенимаю» чужие, я применяю свой собственный рефакторинг.

В .NET мое решение в вашем случае - использовать небольшой трюк, основанный на поддержке спецификации WSDL для компонентного авторинга. Предположим, у вас есть WSDL для двух служб, Abc и Xyz. Я строю "обертку" WSDL вот так:

<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
    targetNamespace="http://services.paschidev.com/wrapper/usecase_a/1/" 
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
  <wsdl:import namespace="http://services.paschidev.com/service_abc/1/" location="AbcService.wsdl" />
  <wsdl:import namespace="http://services.paschidev.com/service_xyz/1/" location="XyzService.wsdl" />
  <wsdl:types />
</wsdl:definitions>

Пропустите это через свою утилиту (успешно протестировано с помощью Visual Studio 2010, команда Добавить ссылку на службу), и все готово.

Мелкий шрифт ... Чтобы все это работало с высокой вероятностью успеха, все WSDL, которые вы хотите объединить, должны следовать этому правилу: общий XSD должен поступать из общих источников.

Если службе Abc требуется {urn:paschidev-com:xsd:common:1}something, а Xyz то же самое, то {urn:paschidev-com:xsd:common:1}something должен исходить из одного и того же исходного URI для обоих WSDL.

Тест для меня довольно прост: я использую QTAssistant (я связан с ним) Extract XSD, указав ее на оболочку WSDL. Когда будет предложено, я разрешаю ему создать проект XSR; если коллекция, созданная из сгенерированных XSD, компилируется нормально, это означает, что нет повторяющихся определений XSD. Если компиляция выдает «уже определенные» ошибки, отчет сообщает мне, какой компонент XSD дублирован, т. Е. Получен из двух или более разных исходных Uris. Я реорганизую каждый компонент, чтобы сохранить один исходный URI; затем попробуйте еще раз.

Иногда, даже если я правильно понимаю XSD, svcutil или xsd все равно могут подавиться; если это произойдет, значит, это что-то не связанное с оболочкой; он проявил бы себя даже без этой оболочки. Это означает, что всегда полезно убедиться, что до того, как произойдет какой-либо рефакторинг, каждый отдельный WSDL работает сам по себе.