Ошибка циклической ссылки при попытке импортировать WSDL в Visual Studio 2013

Question

При импорте файла WSDL, описывающего веб-службу SIRI в Microsoft Visual Studio 2013, я получаю сообщение об ошибке:

Предупреждение 5
Предупреждение о пользовательском инструменте: ошибка с именем FaultName в операции GetProductionTimetable не может быть импортирована. Неподдерживаемый WSDL, часть сообщения об ошибке должна ссылаться на элемент. Это сообщение об ошибке не ссылается на элемент. Если у вас есть доступ для редактирования к документу WSDL, вы можете исправить проблему, сославшись на элемент схемы с помощью атрибута element. C: \ path \ to \ TransportationDemo \ TransportationDemo \ Сервисные ссылки \ ServiceReference \ Reference.svcmap 1

При использовании модифицированной версии WSDL, созданной Министерством Транспорта Израиля, которая исключает множество методов, я получаю еще одну ошибку (среди других ошибок):

Предупреждение 5
Предупреждение о пользовательском инструменте: невозможно импортировать wsdl: portType
Подробно: возникла исключительная ситуация при выполнении расширения импорта WSDL: System.ServiceModel.Description.XmlSerializerMessageContractImporter
Ошибка: недопустимое определение для группы 'ServiceDeliveryBodyGroup' из targetNamespace = ' http://www.siri.org.uk/siri ': ссылка на круговую группу.
XPath to Error Источник: //wsdl: определения [@ targetNamespace = ' http://new.webservice.namespace/ ']/wsdl:portType[@name='SOAP-порт'] C:\ путь \ к \TransportationDemo\TransportationDemo\Service References\ServiceReference1\Reference.svcmap 1

Кажется, что некоторые определения элементов присутствуют в нескольких XSD. Поэтому я попытался использовать svcutil.exe создать прокси-код вручную. Я добавил файл за файлом, необходимым для зависимостей. Сначала у меня был выбор, какой файл добавить, siri.xsd или же siri\siri_base-v1.3.xsd поскольку они оба содержат определения ServiceRequestStructure элемент.

в siri.xsd путь, я добавляю все зависимости и получаю ту же самую циклическую ссылку, упомянутую выше.

в siri\siri_base-v1.3.xsd Я действительно могу генерировать код. Я могу создать SOAPPortClient экземпляр объекта. Я хотел бы призвать GetStopMonitoringServiceRequest метод на это. Но для того, чтобы я мог ввести обязательные поля, мне нужен экземпляр StopMonitoringRequestStructure объект. Это определено в siri_stopMonitoring_service.xsd файл, и не был включен в список XSD, используемых для создания этого прокси. Когда я добавлю этот файл схемы, я должен добавить siri_stopTimetable_service.xsd тоже (для определения MonitoringRefStructure), а затем снова появляется сообщение об ошибке циклической зависимости сверху.

Я в недоумении и был бы признателен за помощь в решении этой проблемы кем-то с большим опытом работы с WSDL с Visual Studio или просто с SOAP-сервисами в целом (или с этим в частности).

Обратите внимание, что SIRI представляет интерфейсы веб-служб в двух отдельных файлах, siri_wsProducer.wsdl а также siri_wsConsumer.wsdl, Насколько я понимаю, я заинтересован во взаимодействии с "Продюсером".

Этот вопрос связан - по-видимому, со стороны другого разработчика, и я был бы очень признателен, если бы он принял участие в этом обсуждении, поскольку, похоже, он нашел решение: импорт WSDL в проект.NET создает только пустое пространство имен

Answer 1

Я немного поиграл с вашими схемами и WSDL и нашел ответ на ваш вопрос, хотя вам это может не понравиться...

• Нет никакой разницы в снятии флажка повторного использования типов, потому что это относится только к ситуациям, когда вы повторно импортируете определения
• После импорта Visual Studio помещает все XSD в ссылку на службу (нажмите "показать скрытые файлы"). Выбрать siri.xsd и он покажет вам, что он не может найти два включения.
• Чтобы исправить проблему включения, я изменил URI включения на абсолютный URI. Это решило проблему, когда Visual Studio не могла найти файлы и затем правильно их копирует.
• При повторной сборке в окне "Вывод отладки" будут отображаться правильные ошибки проверки. Самое главное, он жалуется на переопределения. Мне удалось решить эту проблему, удалив любую ссылку на xml.xsd и упростить несколько мест, где он был использован (xml:lang только). Следующее, что я сделал, это поместил все XSD прямо под корнем и исправил все ссылки в xsl:import а также xsl:include чтобы отразить это. Многие ошибки переопределения теперь исчезли

• Сейчас жалуется на xs:group быть круглым (раньше это делалось, но я хотел, чтобы другие предупреждения были убраны):

  Microsoft.ServiceModel.targets (113,5): ошибка: группа "ServiceDeliveryBodyGroup" из targetNamespace= " http://www.siri.org.uk/siri " имеет недопустимое определение: ссылка на круговую группу.

  Это сложно, потому что мне не удалось отследить, почему он считается круговым, но если это так, это разрешено в XSD. Это импортируется дважды, но это, кажется, не причина, я думаю, что это преднамеренно.

После некоторых дальнейших поисков, кажется, что Microsoft xsd.exe, который похож на код, используемый wsdl.exe, svcutil и добавить ссылку на сервис, признал, что это является ограничением их средств отображения XSD-объект.

Я думаю, что вам лучше всего взять эту группу и сделать ее не круговой. После этого он должен принять схемы как действительные и продолжить. Тот факт, что импортер жалуется на wsdl:portType не указывает вам в правильном направлении. Он жалуется на это, потому что не может отобразить все типы, что приводит к тому, что типы вообще не отображаются, после чего также wsdl:portType неизвестно, отсюда и ошибка.

Вполне возможно, что другие шаги, описанные выше, устареют после того, как вы исправите ServiceDeliveryBodyGroup тип. Другие ошибки были фактически предупреждениями, и я полагаю, что Microsoft по существу игнорирует такие переопределения в любом случае и будет действовать "нормально".

Answer 2

Оказывается, круговая ссылка выглядит так:

• ServiceDeliveryStructure complexType основывается на
• ProducerResponseStructure, который основан на
• abstract ResponseStructure conplexType но содержит
• SiriServiceDeliveryGroup group, который содержит
• StopMonitoringDelivery element, который может быть заменен
• abstract AbstractFunctionalServiceDelivery element, который может быть заменен
• abstract AbstractResponse element который из
• опять же abstract ResponseStructure complexType

отсюда округлость.

Я обнаружил это, комментируя каждый компонент вовлеченной группы, ServiceDeliveryBodyGroup, Он ссылался на несколько element с которых оба type (ссылаясь на некоторые complexType) а также substitutionGroup (ссылаясь на некоторые abstract элемент) набор атрибутов. Удаление type не удалил округлость, а так как abstract Типы были просты, он выделил abstract ResponseStructure complexType, Возвращаясь к ServiceDeliveryBodyGroup, чтобы увидеть, откуда он спускается (это была единственная возможность сделать что-либо круглое после прохождения каждой части его содержимого), быстро обнаружил проблему.

С другой стороны, мне кажется неправильным, что элемент может быть заменен элементом, для которого abstract="true", Но я не так много знаю о XSD. Так что это может иметь смысл.

Вместо того, чтобы пытаться понять это, я решил ServiceDeliveryStructure вместо того, чтобы основываться на ProducerResponseStructure, чтобы содержать группу, которую содержит последний. Я бы предположил, что это эквивалент использования смешанного наследования, а не истинного наследования. На самом деле, AFAIK должен сохранять ту же структуру XML, слегка скрывая дерево зависимостей, но позволяя при необходимости выполнять полный импорт в Visual Studio.

Более подробно я заменяю следующее

<xsd:complexContent>
    <xsd:extension base="ProducerResponseStructure">
        <xsd:sequence>
            <xsd:group ref="ServiceDeliveryBodyGroup"/>
        </xsd:sequence>
        <xsd:attribute name="srsName" type="SrsNameType" />
    </xsd:extension>
</xsd:complexContent>

со следующим

<xsd:sequence>
    <xsd:group ref="ProducerResponseEndpointGroup"/>
    <xsd:group ref="ServiceDeliveryBodyGroup"/>
</xsd:sequence>
<xsd:attribute name="srsName" type="SrsNameType" />

(нота: <xsd:annotation/> тег в оригинальном коде был опущен для краткости)

Я проверю это, и если это будет работать, как ожидалось, я приму свой собственный ответ...