csharpc#xsdwsdlwsdl.exe

Клиент веб-службы с #: несколько методов веб-службы с одинаковым (сложным) типом возврата?

просмотры: 14.7K

В настоящее время я работаю над созданием клиента для веб-службы Java B2B, и я думаю, что определил причину проблемы, которая существует у нас в течение некоторого времени. К сожалению, я не могу опубликовать WSDL.

По-видимому, мой автоматически сгенерированный прокси-код (через wsdl.exe: нужно использовать WSE 3.0 из-за того, что WCF не поддерживает дайджест паролей) не может обрабатывать WSDL веб-службы, имеющую несколько веб-методов с одним и тем же сложным типом возврата.

Возьмем, к примеру, веб-сервис, который определяет следующие методы:

Public ComplexTypeX Blah();
Public ComplexTypeX Blue();
Public ComplexTypeX Foo();
Public ComplexTypeY Bar();

Если в моем файле Reference.cs я закомментирую весь код, который вызывает любые два из Blah (), Blue () или Foo (), то оставшийся раскомментированный метод можно будет назвать без проблем. Однако, если у меня более одного из этих трех методов не закомментированы (скажем, Blah () и Foo ()), то при создании экземпляра кода клиента веб-службы я получаю следующее сообщение об ошибке :

«Метод Бла не может быть отражен». «Элемент XML 'ComplexTypeX' из пространства имен ' http: //some.url ' ссылается на метод и тип. Измените имя сообщения метода с помощью WebMethodAttribute или измените корневой элемент типа с помощью XmlRootAttribute».

Теперь определенно нет ComplexTypeX метода, определенного как часть веб-службы, поэтому я могу только предположить, что .NET (или, по крайней мере, wsdl.exe) не позволяет вам использовать веб-службу, которая возвращает сложную (определяемую пользователем) типы одного и того же типа в нескольких методах ... не так ли?

Источник

Ответов (6)

Я нашел еще один случай, вызывающий ошибку! Вот мой код:

[WebMethod]
public CheckUpdateResponse CheckUpdate()
{
...
}

Хорошо, позвольте мне объяснить: возвращаемый тип CheckUpdateResponse - это структура, CheckUpdate() это метод. Итак, в WSDL .NET автоматически добавляется Responseсуффикс " " к имени методаCheckUpdate в одном из элементов XML для описания возвращаемого значения метода.

Et voilà: он обнаружил повторяющийся элемент и выдает ошибку «Измените имя сообщения метода с помощью WebMethodAttribute ...

Решение ? Я переименовал возвращаемый тип в «CheckUpdateResult», и теперь все работает хорошо!

Надеюсь, это кому-то поможет!

Источник

поэтому я могу только предположить, что .NET (или, по крайней мере, wsdl.exe) не позволяет вам использовать веб-службу, которая возвращает сложные (определяемые пользователем) типы одного и того же типа с помощью нескольких методов ... верно?

Это неверно. Представьте себе, насколько мучительно это было бы, если бы это было правдой - у вас мог бы быть только один метод, который возвращает String, тот, который возвращает Double, тот, который возвращает SomeObject, и т. Д. Это был бы кошмар.

Я не очень хорошо знаком с веб-службами в .NET, но из-за ошибок, которые вы получаете, похоже, что у вас проблемы с пространствами имен XML - возможно, есть конфликт имен. Я бы попытался последовать предложению в сообщении об ошибке, чтобы изменить файл WebMethodAttribute .

Кроме того, если вы не можете опубликовать фрагмент кода / документ, связанный с проблемой, с которой вы столкнулись, из-за некоторых проблем с конфиденциальностью / конфиденциальностью компании, вам следует опубликовать очищенную версию, которая по-прежнему подтверждает ваш тестовый пример. Практически все «чувствительное» должно быть сведено к гораздо более простому фрагменту кода, который все равно передает вашу точку зрения, не выказывая никакой чувствительности.

Источник

Очень странно. Обычно WSDL предоставляет общий тип, а при компиляции с помощью wsdl.exe или svcutil.exe вы получаете общий общий тип для использования в любом количестве методов в одном интерфейсе.

Возникли проблемы при ссылке на несколько независимых WSDL в одном приложении, которые имеют якобы идентичный тип, что приводит к созданию двух разных типов CLR. Есть способы обойти эту проблему - она ​​довольно хорошо известна. Затем возникает проблема сопоставления существующего бизнес-объекта с типом, сгенерированным из WSDL. Еще один ранее исследованный пейзаж.

Но вы говорите о другом.

Источник

Использование WSDL.exe имеет переключатель / sharetypes . Это должно решить проблему.

Более того, я бы не согласился с тем, что это вещь Microsoft, поскольку одни и те же классы представлены как разные сложные типы, находящиеся в нескольких wsdl. Это не лучший абстрактный дизайн.

Готовая справочная документация Microsoft для общих типов Включает функцию совместного использования типов. Эта функция создает один файл кода с определением одного типа для идентичных типов, совместно используемых разными службами (пространство имен, имя и подпись провода должны быть идентичными). Ссылайтесь на сервисы с URL-адресами http: // в качестве параметров командной строки или создайте дисконтный документ для локальных файлов.

Источник

Я просто искал «ссылки на метод и тип» и нашел отчет об ошибке Connect « System.InvalidOperationException: элемент XML * из пространства имен * ссылается на ссылку на метод и тип ». В этом случае есть операция и элемент с одинаковым именем (как локальное имя, так и пространство имен).

Стоит отметить часть ответа от Microsoft:

Мы больше не улучшаем ASMX; мы продолжаем поддерживать его существующие функции, но по возможности рекомендуем использовать WCF.

Источник

Я столкнулся с похожей проблемой, и вот что я нашел:

Я определил сложный тип для возврата в качестве ответа:

public class FooResponse {...}

[WebMethod]
public FooResponse Foo() {...}

Обратите внимание, что здесь важно точное сочетание имен Foo / Foo + Response. Когда я изменил имя метода следующим образом, проблема исчезла:

public class FooResponse {...}

[WebMethod]
public FooResponse Fooxxx() {...}

Я считаю, что происходит то, что .NET пытается автоматически обернуть ответ, исходящий от метода Foo, элементом с именем FooResponse. Использование того же имени в качестве возвращаемого объекта создает двусмысленность. Попробуйте изменить имя вашего объекта ответа или имя вашего метода, чтобы избежать этого столкновения.

Источник