Ответ 1
Вот еще один элемент для проверки:
-
Щелкните правой кнопкой мыши ссылку на службу в обозревателе решений и выберите "Настроить сервисную ссылку"
-
Проверяем, проверено ли "Всегда создавать контракты с сообщением".
Когда я импортирую данную услугу с помощью "Добавить ссылку на службу" в Visual Studio 2008 (SP1), все сообщения Request/Response излишне завернуты в Контракты с сообщениями (называемые → "operationName" + "Request" /Ответ "+" 1 "в конце).
Генератор кода говорит:
// CODEGEN: Generating message contract since the operation XXX is neither RPC nor
// document wrapped.
Ребята, которые генерируют wsdl из службы Java, говорят, что они задают DOCUMENT-LITERAL/WRAPPED.
Приветствуется всякая помощь/указатель/ключ.
Обновление: это образец моего wsdl для одной из операций, которые выглядят подозрительными. Обратите внимание на несоответствие атрибута элемента сообщения для запроса по сравнению с ответом.
<!- imports namespaces and defines elements -->
<wsdl:types>
<xsd:schema targetNamespace="http://WHATEVER/" xmlns:xsd_1="http://WHATEVER_1/" xmlns:xsd_2="http://WHATEVER_2/">
<xsd:import namespace="http://WHATEVER_1/" schemaLocation="WHATEVER_1.xsd"/>
<xsd:import namespace="http://WHATEVER_2/" schemaLocation="WHATEVER_2.xsd"/>
<xsd:element name="myOperationResponse" type="xsd_1:MyOperationResponse"/>
<xsd:element name="myOperation" type="xsd_1:MyOperationRequest"/>
</xsd:schema>
</wsdl:types>
<!- declares messages - NOTE the mismatch on the request element attribute compared to response -->
<wsdl:message name="myOperationRequest">
<wsdl:part element="tns:myOperation" name="request"/>
</wsdl:message>
<wsdl:message name="myOperationResponse">
<wsdl:part element="tns:myOperationResponse" name="response"/>
</wsdl:message>
<!- operations -->
<wsdl:portType name="MyService">
<wsdl:operation name="myOperation">
<wsdl:input message="tns:myOperationRequest"/>
<wsdl:output message="tns:myOperationResponse"/>
<wsdl:fault message="tns:myOperationFault" name="myOperationFault"/>
<wsdl:fault message="tns:myOperationFault1" name="myOperationFault1"/>
</wsdl:operation>
</wsdl:portType>
Обновление 2. Я вытащил все типы, которые у меня были в импортированном пространстве имен (они были в отдельном xsd), в wsdl, поскольку я подозревал, что импорт может инициировать генерацию контракта. К моему удивлению, это было не так, и все типы, определенные в wsdl, ничего не меняли.
Затем я (из отчаяния) начал строить wsdls с нуля и играл с атрибутами maxOccurs
атрибутов элемента, содержащихся в атрибуте последовательности, я смог воспроизвести поведение генерации нежелательных сообщений.
Здесь образец элемента:
<xsd:element name="myElement">
<xsd:complexType>
<xsd:sequence>
<xsd:element minOccurs="0" maxOccurs="1" name="arg1" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Играя с maxOccurs
на элементах, которые используются как сообщения (все запросы и ответы в основном), происходит следующее:
Я не смог воспроизвести это на моем производстве wsdl еще из-за того, что гнездование типов идет очень глубоко, и мне потребуется время, чтобы тщательно изучить его. Между тем я надеюсь, что он может позвонить в колокол - любая помощь, которую высоко ценят.
Вот еще один элемент для проверки:
Щелкните правой кнопкой мыши ссылку на службу в обозревателе решений и выберите "Настроить сервисную ссылку"
Проверяем, проверено ли "Всегда создавать контракты с сообщением".
Вы пытались изменить WSDL так, чтобы для каждого экземпляра элемента part = "tns: myOperation" name= "запрос", изменив значение атрибута name на "параметры".
У меня была такая же проблема, и это решило ее.
Я использовал это:
<wsdl:message name="Method">
<wsdl:part name="parameters" element="s0:Method"/>
</wsdl:message>
<wsdl:message name="MethodResponse">
<wsdl:part name="parameters" element="s0:MethodResponse"/>
</wsdl:message>
Вместо:
<wsdl:message name="Method">
<wsdl:part name="request" element="s0:Method"/>
</wsdl:message>
<wsdl:message name="MethodResponse">
<wsdl:part name="response" element="s0:MethodResponse"/>
</wsdl:message>
Я считаю, что кто-то упомянул об этом раньше, но я пока не могу подтвердить их ответ!
Хотя я знаю, что это длинная устаревшая запись, для тех, кто наткнулся на эту же проблему:
Двойная проверка того, что прокси-сервер, который был сгенерирован, не содержит никаких зубчатых массивов, например.
(С#)
private string[][] mystring;
(VB.NET)
Private myString()() As String
Вы пытались использовать scvutil Goto → Startmenu/Visual Studio 2008/Инструменты/VS Command Prompt
Введите svcutil, затем проверьте параметры, особенно параметр /wrapped. В конечном счете используйте это, чтобы сгенерировать свой прокси-сервер, он дает вам больше контроля над тем, что происходит