Я пишу клиент C#, который вызывает веб-службу, написанную на Java (другим человеком). Я добавил веб-ссылку на свой клиент и могу нормально вызывать методы веб-службы.
Служба была изменена для возврата массива объектов, а клиент неправильно анализирует возвращенное сообщение SOAP.
MyResponse[] MyFunc(string p)
class MyResponse
{
long id;
string reason;
}
Когда сгенерированный мной прокси C# вызывает веб-службу (с использованием SoapHttpClientProtocol.Invoke), я ожидаю массив MyResponse [] длиной 1, то есть один элемент. После вызова Invoke я получаю элемент с id = 0 и reason = null, независимо от того, что на самом деле возвращает служба. Используя сниффер пакетов, я вижу, что служба возвращает то, что кажется законным мыльным сообщением с идентификатором и причиной, установленными в ненулевые значения.
Есть ли какой-нибудь трюк, чтобы заставить клиента C# вызвать веб-службу Java, которая возвращает someobject []? При необходимости я буду работать над подготовкой демо-версии.
Редактировать: Это веб-ссылка через «Добавить веб-ссылку ...». VS 2005, .NET 3.0.





Прошло некоторое время, но я, кажется, помню, что у меня были проблемы с небольшими различиями в том, как обрабатывались пространства имен по умолчанию между веб-службами .Net и Java.
Дважды проверьте сгенерированный прокси-класс C# и все пространства имен, объявленные внутри (особенно значения по умолчанию xmlns = ""), на соответствие ожиданиям службы Java. Вероятно, будут очень тонкие различия, которые вам придется воссоздать.
В этом случае вы должны предоставить дополнительные объявления пространств имен в атрибутах C#.
Из вашего вопроса похоже, что у вас был клиент, работающий в какой-то момент, а затем служба была изменена для возврата массива. Убедитесь, что вы повторно сгенерировали прокси, чтобы возвращенное сообщение SOAP десериализовалось на клиенте. Было непонятно, что вы сделали это - просто убедился.
Ваше понимание правильное. Это работало до тех пор, пока я не добавил метод, возвращающий MyResponse []. Я обновил ссылку и прокси перестроили.
Благодаря Сиань у меня есть решение.
WSDL для службы включает строку
<import namespace = "http://mynamespace.company.com"/>
Мыло, которое клиент отправил на сервер, имело следующий атрибут для всех элементов данных:
xmlns = "http://mynamespace.company.com"
Но полезная нагрузка xml ответа (от службы обратно клиенту) включала это пространство имен в нет. Повозившись с HTTP-ответом (который я получил с помощью WireShark), я заметил, что прокси-класс .NET правильно улавливал значения MyResponse, если я принудительно использовал атрибут xmlns для каждого возвращаемого элемента данных.
За исключением изменения службы, которую я не контролирую, обходной путь заключается в редактировании сгенерированного VS прокси-класса (например, Reference.cs) и поиске таких строк:
[System.Xml.Serialization.XmlTypeAttribute(Namespace = "http://mynamespace.company.com")]
public partial class MyResponse {
и закомментируйте строку атрибута XmlType. Это скажет CLR искать элементы ответа в пространстве имен по умолчанию, а не в том, который указан в wsdl. Вы должны повторять это всякий раз, когда обновляете ссылку, но, по крайней мере, это работает.
Спасибо, что разместили свое решение, оно вернуло море воспоминаний!
Вы используете «Добавить веб-ссылку» (.NET 2.0) или «Добавить ссылку на службу» (.NET 3.0)?