WCF-клиент, получающий значение нулевого ответа

У меня есть простой потребительский клиент wcf, который отправляет запросы «эха» стороннему производителю на Java. Я некоторое время боролся за правильную работу WS-Security, но теперь могу отправлять запросы и получать ответы. Только когда ответ достигает моего клиента, значение равно null.WCF-клиент, получающий значение нулевого ответа

Я использовал IClientMessageInspector, чтобы проверить, что у меня есть правильный ответ, но мой вызов службы всегда возвращает null.

Вот мой код клиента; (Вызов «MyEndPointBehavior» просто добавляет сообщение инспектора)

string echoString = EchoTesttextbox.Text; 

string url = "https://somewhere.com/uk-producer/UKService"; 

// create the endpoint address 
EndpointAddress endPointAddress = new EndpointAddress(new Uri(url), EndpointIdentity.CreateDnsIdentity("TestProducer")); 

PortBindingClient client = new PortBindingClient("Port12", endPointAddress); 
client.ClientCredentials.ClientCertificate.SetCertificate(StoreLocation.LocalMachine, StoreName.Root, X509FindType.FindByThumbprint, "....."); 
client.ClientCredentials.ServiceCertificate.SetDefaultCertificate(StoreLocation.LocalMachine, StoreName.TrustedPeople, X509FindType.FindByThumbprint, "....."); 
client.Endpoint.Behaviors.Add(new MyEndpointBehavior()); 

string response = String.Empty; 
response = client.echo(echoString); 

MessageBox.Show(response);

И мое сообщение код inpector;

public void AfterReceiveReply(ref System.ServiceModel.Channels.Message reply, object correlationState) 
{ 
    // Implement this method to inspect/modify messages after a message 
    // is received but prior to passing it back to the client 

    // make a copy of the reply that we can play with 
    MessageBuffer buffer = reply.CreateBufferedCopy(Int32.MaxValue); 
    // the message variable holds a reference to a copy of the initial reply 
    Message message = buffer.CreateMessage(); 

    // assign a copy back to the ref received so it can continue undisturbed 
    reply = buffer.CreateMessage(); 

    StringWriter stringWriter = new StringWriter(); 
    XmlTextWriter xmlTextWriter = new XmlTextWriter(stringWriter); 
    message.WriteBody(xmlTextWriter); 
    xmlTextWriter.Flush(); 
    xmlTextWriter.Close(); 

    string body = stringWriter.ToString(); 

}

Мой вопрос заключается в том, что происходит между IClientMessageInspector.AfterReceiveReply и пытается показать отклик в моей MessageBox? Если я могу попытаться понять, что происходит, я могу попробовать и решить, почему ответ не проходит.

источник

2013-09-09 David

Ну, это было очень неприятно. Причина, по которой я получал нулевое значение, имела отношение к пространству имен.

В IClientMessageInspector я мог осмотреть тело SOAP и увидеть это

<soapenv:Body wsu:Id="Id-1555290177" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> 
<me:EchoResponse xmlns:me="http://somewhere.com/uk-producer/UKService">test11</me:EchoResponse> 
</soapenv:Body>

WSDL, и Reference.cs (я генерироваться мой прокси-сервер с помощью «Add Service Reference» особенность VS2012 от 3 партии WSDL) показать это;

[System.ServiceModel.MessageBodyMemberAttribute(Name="EchoResponse", Namespace="http://somewhere.com/uk-producer/UKService/", Order=0)] 
public string EchoResponse1;

И долгое время все выглядело нормально. Но потом, из-за расстройства я попытался изменяя Reference.cs к этому

[System.ServiceModel.MessageBodyMemberAttribute(Name="EchoResponse", Namespace="http://somewhere.com/uk-producer/UKService", Order=0)] 
public string EchoResponse1;

я только снял последнюю косую черту пространства имен

И все сработало.

источник

2013-09-10 12:09:26 David

Спасибо, что поделились вашей резолюцией Дэвида. Я столкнулся с некоторыми значениями свойств null в прокси-классе моего ответа от службы.Благодаря использованию SoapUI я смог проверить ответ, который я получал и обнаружил, что, хотя пространство имен было верным, было несоответствие в схеме пространства имен и схеме ответа. Мы используем BTDF для наших развертываний, и проблема была вызвана тем, что папка App_Data не обновляется в IIS после внесения изменений в схемы. – Hoopla

Подробнее о том, как правильно определить пространство имен, которое требуется, - http: stackoverflow.com/a/31469374/1696326 – Agalo

Сначала настройте сервис (даже заглушку), которая не использует никакой безопасности. Затем посмотрите сообщение, которое оно отправляет, и сравните с сообщением, которое отправляет ваш инспектор.

источник

2013-09-09 12:43:14

Хорошо я сделал это - я не понимаю, почему, но дал ему идти в любом случае. Есть очевидные различия, в основном из-за элементов безопасности в заголовке Soap. – David

в общем, нормально, чтобы ваш инспектор запретил любую безопасность, чтобы сообщения были одинаковыми. Нуль обычно появляется, когда есть разница в именах или именах корневых элементов. –

Это работает. Удалите атрибут стиля тела и повторите попытку.

Приведенные ниже атрибуты передать нулевое значение параметров

[WebInvoke(Method = "POST", ResponseFormat = WebMessageFormat.Json, **BodyStyle = WebMessageBodyStyle.WrappedRequest**, 
     UriTemplate = "/GetactivityDetailsByActivityId")]

Ниже работал прекрасный

[WebInvoke(Method = "POST", ResponseFormat = WebMessageFormat.Json, 
     UriTemplate = "/GetactivityDetailsByActivityId")]

источник

2017-08-31 20:20:24 extractor

WCF-клиент, получающий значение нулевого ответа

ответ

Смежные вопросы