Пространство имен при записи XDTO #723082

Добрый день! Обмениваюсь со сторонним веб сервисом. Создал ws определение и ws прокси. Вызываю метод веб сервиса - получаю ошибку. Выяснили, что проблема с пространством имен. У меня: <soap:Envelope xmlns:soapenv="; xmlns:soapenc="; xmlns:xsd="; xmlns:xsi="; xmlns:soap="; <soap:Header/> <soap:Body> <getList xmlns="; xmlns:xs="; xmlns:xsi="; <param>test</param> А нужно: <soap:Envelope xmlns:soapenv="; xmlns:soapenc="; xmlns:xsd="; xmlns:xsi="; xmlns:soap="; xmlns:int="; <soap:Header/> Другими словами, нужно пространство имен из GetList перенести в soap:Envelope. А как это сделать, если 1С сам генерирует soap уровень?

С точки зрения стандарта приведенные фрагменты xml идентичны. Т.е. любой xml parser должен разобрать их одинаково. Уверен, что проблема в этом? Если уверен - кажется, что способов повлиять на форматирование xml при использовании WSПрокси нет. Тогда остается вместо WSПрокси самому слать HTTP-запросы. Т.е. самому формировать xml через ЗаписьXML и передавать его в качестве тела в HTTPЗапрос. Правда тогда придется самому разбирать ответ.

В первом и во втором варианте элемент getList находится в одном пространстве имен, и оно "; В первом варианте оно там, потому что объявляется xmlns="; - пространство имен по умолчанию (когда элемент не квалифицирован префиксом). Во втором варианте, благодаря объявлению xmlns:int="; - для этого пространства имен определяется префикс int, но элемент getList там квалифицирован как раз этим префиксом. А вот вложенный в него элемент param не квалифицирован, оответственно в первом варианте он в пространстве имен по умолчанию, а это ";; а во втором варианте, оно не определено совсем.

Если тип свойства однозначно определен схемой - то зачем его квалифицировать?

Тут мне еще вариант предложили, оставить как есть и заменить только: на: Есть ли возможность при создании xdto как-то явно указать для вложенного элемента xmlns?

Сталкивался с такой же проблемой. Получилось решить только "собиранием" хмл вручную. Может кто-нибудь подскажет более простой способ?

Спасибо, буду читать!=)

Какой-то уж очень замороченный способ...

И чего там замороченного? Создать библиотеку 1 минута, написать код даже быстрее чем в 1С зная NET.

Я пролистал весь тред и никак не могу понять как сие можно к данной проблеме применить?

Там смысл такой, что нужно создать клиента  WCF

Смысл такой, что в .NET гораздо более приспособлен к работе с сервисами, а   - компонента, которая связывает сборку .NET и 1С. Ну это очень схематично и коротенько. Т.е. в ограниченной по возможностям 1С можно использовать безграничные возможности .NET. Я уже пользую больше года и не мыслю, как можно без этого

Кстати в новой версии исправил метод public object СоздатьКлиентаWCFConfigFile(string ИмяФайла, object TChannel, string endpointConfigurationName, object endpointAddress=null,string UserName=null, string Password=null)         {             ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap;             {

У меня нет работы в веб-сервисами. У меня больше всякие системные вещи: сокеты, ком-порты, бинарные файлы, прямой доступ к скулю и пр. Кстати, большой блок по GDI+, рисую карты Яндекс гораздо быстрее, чем посредством HTML

Нда, этому делу я точно ума не дам. Придется видимо писать в xml, а потом заменой "param" на "param xmlns=""" менять. А тот xml что получиться по HTTP отправлять...

Ясно

Кстати работая с ЭДИ пришлось заняться кодогенерацией из xsd. Вот этот лучше всех разобрал Кстати здесь про подпись

17+

Так в .NET подписи не по ГОСТ, а у меня только с ЭСФ. У Крипто-ПРО есть сборка для криптографии по ГОСТ, но они за нее денег просят, в принципе 1С-овская устраивает.

Ну если поскать на просторах инета то можно найти и по ГОСТУ например

Ну вопрос, будет ли это совместимо с ключевыми носителями Крипто-ПРО? Да и вообще-то противоречит законодательству: стойкие криптопровайдеры могут разрабатывать только разработчики, лицензированные ФСБ. Ну и задачи нет все переписать на .NET. Только то, что не работает, отсутствует или гораздо проще сделать на .NET. В остальном пусть 1С тоже что-то делает.

Кстати а в 1С появилась функция цифровой подписи по ГОСТу? У меня девчонки подписывают через сайт, а значит есть СОМ библиотеки подписи. Меня просто заинтересовал алгоритм подписи, так как он должен быть открытым

На 8.2 целый объект - МенеджерКриптографии. На сайте например у лерадаты вроде java-applet, но у разработчика криптопровайдера - Крипто-ПРО есть и COM и .NET-сборка. Алгоритм открытый, но на разработку конкретной реализации нужна лицензия, типа ФСБ проверит: не сделал ли ты закладки.

Спасибо, чего то я его пропустил