wsdl.exe Ошибка:Не удалось импортировать привязку '...' из пространства имен '...'

Question

При запуске wsdl.exe на WSDL, который я создал, я получаю эту ошибку:

Ошибка:Не удалось импортировать привязку 'SomeBinding' из пространства имен 'SomeNS'.

• Не удалось импортировать операцию "SomeOperation".
• Эти члены не могут быть производными.

Я использую стиль document-literal и, насколько мне известно, следую всем правилам.

Подводя итог, у меня есть действующий WSDL, но инструменту это не нравится.

Что я ищу, так это если у кого-то есть большой опыт работы с инструментом wsdl.exe и он знает о какой-то секретной уловке, которой нет у меня.

Answer 1

Я наткнулся на то же самое сообщение об ошибке.Покопавшись некоторое время, выяснил, что в дополнение к файлу wsdl можно предоставлять xsd-файлы.Итак, включили / импортировали .xsd файлы в дополнение к .wsdl в конце команды wsdl следующим образом:

wsdl.exe MyWebService.wsdl myXsd1.xsd MyType1.xsd myXsd2.xsd ...

Wsdl выдал несколько предупреждений, но он создал интерфейс службы ok.

Answer 2

иногда вам приходится менять свой код.названия частей сообщения не должны совпадать ;)

<wsdl:message name="AnfrageRisikoAnfrageL">
    <wsdl:part name="parameters" element="his1_0:typeIn"/>
</wsdl:message>
<wsdl:message name="AnfrageRisikoAntwortL">
    <wsdl:part name="parameters" element="his1_0:typeOut"/>
</wsdl:message>

к этому:

<wsdl:message name="AnfrageRisikoAnfrageL">
    <wsdl:part name="in" element="his1_0:typeIn"/>
</wsdl:message>
<wsdl:message name="AnfrageRisikoAntwortL">
    <wsdl:part name="out" element="his1_0:typeOut"/>
</wsdl:message>

Answer 3

@решение hhhv правильное.Существует обходной путь, который не требует от вас добавления xsds вручную.

Тогда иди на свою службу вместо того, чтобы идти ?wsdl перейти к ?singleWsdl (скриншот ниже)

затем сохраните страницу как .wsdl файл (он предложит .svc так что измени это)

затем откройте Visual studio command prompt вы можете найти его в (Win 7) Пуск -> Все программы -> Visual Studio 2013 -> Инструменты Visual Studio -> Командная строка VS2013 x64 Native Tools (может быть что-то похожее)
Затем выполните следующую команду в Visual studio command prompt (где вместо C:\WebPricingService.wsdl указано место, где вы сохранили свой wsdl, если только не случится так, что мы думаем очень похоже и выбираем одно и то же имя файла и местоположение, что вызывает беспокойство)

wsdl.exe C:\WebPricingService.wsdl

Это должно выдавать вам несколько предупреждений, как сказал @thehhv, но все равно генерировать клиента в C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\WebPricingService.cs (или куда бы он ни поместил его на вашем компьютере - проверьте вывод консоли, где он читает "Файл записи")

Надеюсь, это сэкономит вам немного времени.

Answer 4

В моем случае проблема была другой и хорошо описана здесь:

Всякий раз, когда имя части является "параметрами", .Net предполагает, что используется doc / lit / wrapped, и соответствующим образом генерирует прокси.Если даже используется слово "параметры", wsdl не является doc / lit / wrapped (как в последнем примере) .Net может выдать нам некоторую ошибку.Какая ошибка?Вы правильно догадались:"Эти члены не могут быть производными".Теперь мы можем понять, что означает эта ошибка:.Net пытается опустить корневой элемент, поскольку считает, что используется doc / lit / wrapped.Однако этот элемент не может быть удален, поскольку он не является фиктивным - он должен быть активно выбран пользователем из нескольких производных типов.

Исправление заключается в следующем, и оно отлично сработало для меня:

Способ исправить это - открыть wsdl в текстовом редакторе и изменить название детали из "параметры" Для "параметры 1".Теперь .Net будет знать, что нужно сгенерировать документальный / освещенный / простой прокси.Это означает, что новый класс-оболочка появится в качестве корневого параметра в прокси-сервере.Хотя это может быть немного более утомительный api, это никак не повлияет на проводной формат, и прокси-сервер полностью совместим.

^{(выделено мной)}

Answer 5

На случай, если кто-то наткнется на эту стену, вот что вызвало ошибку в моем случае:

У меня операция:

<wsdl:operation name="FormatReport">
  <wsdl:documentation>Runs a report, which is returned as the response</wsdl:documentation>
  <wsdl:input message="FormatReportRequest" />
  <wsdl:output message="FormatReportResponse" />
</wsdl:operation>

который принимает входные данные:

<wsdl:message name="FormatReportRequest">
  <wsdl:part name="parameters" element="reporting:FormatReportInput" />
</wsdl:message>

и еще одна операция:

<wsdl:operation name="FormatReportAsync">
  <wsdl:documentation>Creates and submits an Async Report Job to be executed asynchronously by the Async Report Windows Service.</wsdl:documentation>
  <wsdl:input message="FormatReportAsyncRequest" />
  <wsdl:output message="FormatReportAsyncResponse" />
</wsdl:operation>

получение входных данных:

  <wsdl:message name="FormatReportAsyncRequest">
    <wsdl:part name="parameters" element="reporting:FormatReportInputAsync" />
  </wsdl:message>

И входные элементы являются экземплярами двух типов:

<xsd:element name="FormatReportInput" type="reporting:FormatReportInputType"/>
<xsd:element name="FormatReportInputAsync" type="reporting:FormatReportAsyncInputType"/>

Вот в чем загвоздка - в reporting:FormatReportAsyncInputType тип расширяет (производен от) reporting:FormatReportInputType Тип.Это то, что, по-видимому, сбивает инструмент с толку и вызывает ошибку "Эти элементы могут быть не производными".Вы можете обойти это, следуя предложению в принятом ответе.

Answer 6

В случае, если вы делаете это с UPS Shipping wsdl и хотите поменять URL-адреса dev на prod при сборке для разных регионов (debug, dev, prod) и т.д.Вы должны использовать приведенную ниже команду для создания файла vb или C # из Ship.wsdl, а затем переопределить значения в этом случае файла Ship.vb.

WSDL /Language:VB /out:"C:\wsdl\Ship.vb" "C:\wsdl\Ship.wsdl"  C:\wsdl\UPSSecurity.xsd  C:\wsdl\ShipWebServiceSchema.xsd  C:\wsdl\IFWS.xsd  C:\wsdl\common.xsd