wsdl.exe Ошибка:Не удалось импортировать привязку '...' из пространства имен '...'
Вопрос
При запуске wsdl.exe на WSDL, который я создал, я получаю эту ошибку:
Ошибка:Не удалось импортировать привязку 'SomeBinding' из пространства имен 'SomeNS'.
- Не удалось импортировать операцию "SomeOperation".
- Эти члены не могут быть производными.
Я использую стиль document-literal и, насколько мне известно, следую всем правилам.
Подводя итог, у меня есть действующий WSDL, но инструменту это не нравится.
Что я ищу, так это если у кого-то есть большой опыт работы с инструментом wsdl.exe и он знает о какой-то секретной уловке, которой нет у меня.
Решение
Я наткнулся на то же самое сообщение об ошибке.Покопавшись некоторое время, выяснил, что в дополнение к файлу wsdl можно предоставлять xsd-файлы.Итак, включили / импортировали .xsd файлы в дополнение к .wsdl в конце команды wsdl следующим образом:
wsdl.exe MyWebService.wsdl myXsd1.xsd MyType1.xsd myXsd2.xsd ...
Wsdl выдал несколько предупреждений, но он создал интерфейс службы ok.
Другие советы
иногда вам приходится менять свой код.названия частей сообщения не должны совпадать ;)
<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>
@решение hhhv правильное.Существует обходной путь, который не требует от вас добавления xsd
s вручную.
Тогда иди на свою службу вместо того, чтобы идти ?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
(или куда бы он ни поместил его на вашем компьютере - проверьте вывод консоли, где он читает "Файл записи")
Надеюсь, это сэкономит вам немного времени.
В моем случае проблема была другой и хорошо описана здесь:
Всякий раз, когда имя части является "параметрами", .Net предполагает, что используется doc / lit / wrapped, и соответствующим образом генерирует прокси.Если даже используется слово "параметры", wsdl не является doc / lit / wrapped (как в последнем примере) .Net может выдать нам некоторую ошибку.Какая ошибка?Вы правильно догадались:"Эти члены не могут быть производными".Теперь мы можем понять, что означает эта ошибка:.Net пытается опустить корневой элемент, поскольку считает, что используется doc / lit / wrapped.Однако этот элемент не может быть удален, поскольку он не является фиктивным - он должен быть активно выбран пользователем из нескольких производных типов.
Исправление заключается в следующем, и оно отлично сработало для меня:
Способ исправить это - открыть wsdl в текстовом редакторе и изменить название детали из "параметры" Для "параметры 1".Теперь .Net будет знать, что нужно сгенерировать документальный / освещенный / простой прокси.Это означает, что новый класс-оболочка появится в качестве корневого параметра в прокси-сервере.Хотя это может быть немного более утомительный api, это никак не повлияет на проводной формат, и прокси-сервер полностью совместим.
(выделено мной)
На случай, если кто-то наткнется на эту стену, вот что вызвало ошибку в моем случае:
У меня операция:
<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
Тип.Это то, что, по-видимому, сбивает инструмент с толку и вызывает ошибку "Эти элементы могут быть не производными".Вы можете обойти это, следуя предложению в принятом ответе.
В случае, если вы делаете это с 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