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

Question

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

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

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

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

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

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

Answer 1

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

wsdl.exe myWebService.wsdl myXsd1.xsd myType1.xsd myXsd2.xsd ...

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

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

@ thehhv решение верное. Есть обходной путь, который не требует добавления xsd s вручную.

Перейдите к вашему сервису, а затем вместо ?wsdl перейдите на ?singleWsdl (скриншот ниже)

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

затем откройте Visual studio command prompt, вы можете найти его в (Win 7) Пуск -> Все программы -> Visual Studio 2013 -> Инструменты Visual Studio -> VS2013 x64 Командная строка собственных инструментов (может быть что-то похожее)
Затем выполните следующую команду в 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 будет знать, чтобы сгенерировать прокси doc / lit / bare. Это означает, что новый класс-оболочка появится в качестве корневого параметра в прокси. Хотя это может быть немного более утомительным API, это не окажет никакого влияния на формат проводника, и прокси полностью совместим.

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

Answer 5

В случае, если вы делаете это с UPS Shipping wsdl и хотите поменять местами dev и pro, когда вы строите для разных регионов (отладка, 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

Answer 6

В случае, если кто-то попадет в эту стену, вот что вызвало ошибку в моем случае:

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

<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. Вот что, похоже, сбивает с толку инструмент и приводит к тому, что «эти члены не могут быть производными». ошибка. Вы можете обойти это после предложения в принятом ответе.