Привязки на основе SOAP распаковывают конверт SOAP, поэтому вам не нужно определять типы конвертов SOAP.WebHttpBinding, который, как вы говорите, используете, который ничего не знает о SOAP, будет ожидать, что тип контракта (аргумент метода службы IService.Test
) будет соответствовать всему телу HTTP, поэтому я вижу логику того, чтовы делаете, однако я не думаю, что нужно работать против такой инфраструктуры.
Чтобы исправить этот сценарий, сделайте пару вещей:
- измените вашу реализациюIService.Test для получения аргумента типа
Notifications
string Test(Notifications notifications)
- изменить конфигурацию службы, указав привязку SOAP на основе HTTP, возможно BasicHttpBinding
<endpoint address="/relativeaddress/" binding="basicHttpBinding" ... />
- Я думаю, что привязка SOAP, вероятно, будет игнорировать
WebInvokeAttribute
, но для большей безопасности удалите ее.Для связывания SOAP это излишне, потому что SOAP всегда POST.
Не думаю, что вам нужно удалять типы Envelope
и Body
, но они ничего не сделают, если онине указано, что вы хотите.Привязки WCF изначально понимают конверт SOAP и не нуждаются в его указании; для этого необходимо предоставить типы элемента Body SOAP.
Ваш образец XML содержит один экземпляр Notification
в Notifications
, но название подразумевает, что этот дочерний элемент может повторяться - если это так, я не думаю, что сгенерированные классы будут работать для вас, потому что класс Notifications
имеет единственное свойство Notification
- генератор, который вы связалиу меня нет возможности узнать это, так что я ни в чем не виноват.Я добавил копию элемента Notification
в качестве одноуровневого элемента и снова запустил его - на этот раз он сгенерировал элемент списка:
[XmlElement(ElementName="Notification", Namespace="http://soap.sforce.com/2005/09/outbound")]
public List<Notification> Notification { get; set; }
Вы можете использовать инструмент xsd.exe
, поставляемый с Visual Studio (яподумайте) для генерации классов - см. документацию .Я не удивлюсь, если этот веб-инструмент управляет этим за кулисами, но я бы доверял xsd.exe
в создании классов, которые наилучшим образом соответствовали бы ожиданиям WCF.