Develop Reference

How to figure out exactly where the error is in the deserialization of WCF SOAP XML response?

Apologies if this has been asked before but it seems I cannot find the answer.
I am trying to consume a SOAP Web Service using WCF. I've used Visual Studio 2015's Add Service Reference to add the service reference and generate all code.
The service call fails with the following CommunicationException error:
System.ServiceModel.CommunicationException : Error in deserializing body of reply message for operation 'XYZ'.
---- System.InvalidOperationException : There is an error in XML document (2, 979).
-------- System.FormatException : Input string was not in a correct format.
I understand the error; I understand that something (an element value, probably) in the XML response document cannot be deserialized according to what the svcutil's generated code dictates.
I am logging the XML response document. Also, I am comparing it with the SoapUI response and they both look identical.
SO how can I figure out exactly where the problem is in the XML document? Is there any method, technique or trick to step through the deserialization process and pinpoint the faulty bit? It is a rather long XML document ...
IMHO, at this point the WCF behaves like a black box that I cannot look inside it.
TIA,

Turn on WCF Trace:
https://learn.microsoft.com/en-us/dotnet/framework/wcf/diagnostics/tracing/configuring-tracing
Use the following application to view the results:
https://learn.microsoft.com/en-us/dotnet/framework/wcf/service-trace-viewer-tool-svctraceviewer-exe

Well, it seems one cannot really find exactly where such a deserialization error lies. Things get even worse if the service developer is not the same person as the service client developer.
In my case, the error was due to a mismatch of a data type between the service and the generated client code. The origin of the problem was the erroneous XSD. In order to find the error, I had to contact the service developer who managed to locate it.
Generally speaking, this is one of those things that make you feel you are losing control over your code; much like that point in a project when you want to look the source code of a library but you just can't because you don't own it. This is something all developers who decide to work on web services consuming project should be aware of.

For debugging, you can use Fiddler2 easily to capture any web traffic, including the full xml of a SOAP request/response (and it even handles SSL easily, unlike Wireshark)
For logging... I wish I knew. Sorry.
Also, dupe of In C#, How to look at the actual SOAP request/response in C#

WCF Service using json.net MediaTypeFormatter example

Question
Is there an up-to-date example showing how to replace the default DataContractJsonSerializer with Json.Net serializer in a WCF 4.5 Service?
Background
As seems to be a common request, I want to replace the default DataContractJsonSerializer with Json.Net serializer. The first approach I came across was provided by Carlos Figueira here. This does work, but as pointed out at the end of the article (paraphrasing somewhat):
this is not production-ready code...tested it for a few contracts...cannot guarantee that it will work for all scenarios…for simplicity sake it doesn’t have a lot of error handling which a production-level code would...it’s not too easy to integrate any new formats in the existing WCF REST pipeline...had to deal with formatters, Message objects, take a dependency on a content type mapper, just to be able to use this different serializer...even after all of this...not completely integrated with the pipeline – UriTemplates aren’t supported...
Which all makes me a bit nervous. However at the end there is a mention of WCF API with a link to an discussion which has these lines of code:
var hostConfig = (HttpHostConfiguration) config;
hostConfig.OperationHandlerFactory.Formatters.Insert(0, new NewtonsoftJsonFormatter());
as well as how to override a formatter. The problem is that I can't get this to work in a WCF service. After including a bunch of additional NuGet packages the formatter compiles, but my service is never called. Each page I come across, seems to have different configuration code. I have tried the approaches outlined here, here, here, here and here (to list a few). Some use HttpHostConfiguration, some use GlobalConfiguration, some use OperationHandlerFactory. I think that part of the problem is that a number of these approaches are old and from different technologies - WCF WEB API, ASP.NET API, ASP.NET MVC.
While I can get the formatter to compile, it is never called, which makes me think that it is a configuration issue. I could post some code, but I am not sure exactly which part is incorrect. I have considered the approach of returning the generic Message object and formatting each object to a Message with json, but I would prefer to only do this as a last resort as it makes the return types for the service less clear. Which brings me to my the question show above.

Mapping a bad wsdl

Im attempting to interact with another company's web service via WSDL.
I've imported it into VS2010 as a service reference, I can make request just fine. The problem is, the return types are strings (of xml). Now I'm fairly new to the WSDL deal, but from what I've read there should be return types in the contract and then the service reference would auto-magically generate classes for me.
How do I remedy this?
I suppose I could map the strings of XML, if so, can someone please
show me a nice example? As I have tried with no avail.
Could I tell the web service to use a return type that I specify?
Or, do i have the wrong idea about WSDL? And if so, could someone please explain inconsistencies in my understanding?

Your basic idea is correct, having a service wsdl should define the return and input objects to the service operations. The service provider might have a valid reason for just returning you strings or maybe he just didn´t know better.
For you the WSDL is the final frontier, unless your business partner is able to provide a new one you cannot change the service interface, so you have to deal with the XML strings.
Check out XMLDocument, it offers the Load() method accepting a string. If it fails, chances are you´re missing an XSD or you dont have a valid/wellformed xml document contained inside the string. In both cases it´s your business partner who has to correct the error or provide further information.

Customizing the xmlns:a= tag in a soapresponse from WCF

I'm creating a service to respond to calls.
However the client(not written by me) cannot read the response.
What we have located is that this seems to be due to th missmatching namespace in the
xmlns:a="http://schemas.datacontract.org/2004/07/MyProject.Classes"
Is there anyway to override this namespace?
I'm rather sure it is.
The [ServiceBehavior] tag has the "http://correctnamespace.com" NameSpace
The BindingNameSpace in the app.config has the "http://correctnamespace.com" Namespace
The [ServiceContract] has the "http://correctnamespace.com" Namespace
I've looked at the OperationsContract to see if I can locate it but without luck.
the namespace needs to be "http://correctnamespace.com"
Below is a full example of the Upper part of the SOAPresponse
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<getAddressResponse xmlns="http://correctnamespace.com">
<getAddressReturn xmlns:a="http://schemas.datacontract.org/2004/07/MyProject.Classes" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<a:PropertyChanged i:nil="true" xmlns:b="http://schemas.datacontract.org/2004/07/System.ComponentModel"/>
<a:addressField>Happystreet 21</a:addressField>
I hope someone can help me sort this ut ASAP.
Added information
The service is created to fit he client.
The client is predesigned and the service is created based on a WSDL file provided from the client creator.
Also note that the client cannot be modified. :(

I have a couple suggestions.
First, assuming that the server side code sand stubs are all correct and functioning properly, ask the client to regen the client side stubs. It is possible that somehow the stub they are using is old or has been modified.
Second, if the serverside is also not working properly I recommend recreating your WSDL from scratch. Proper SOAP coding is WSDL to code creation. So if your WSDL was generated by a tool it will have a certain naming convention and while you can manually change things like your xmlns, if you miss one (which is what it sounds like happened) it will mess up your code. So go back and make the WSDL from scratch and generate the code classes from the WSDL that way you can name everything the way you want it to be named.

Based on the added information, I again have two suggestions.
First, is that you will have to go in and manually change the soap response AddressReturn namespace and follow the chain so that any references to the aforementioned response has the correct namespace. It will be tedious and annoying, but you could program an xml parser that can find any references to such field and make the necessary changes in both the schema and the WSDL.
Second is to use the WSDL provided to you by the client in order to create your own WSDL that will work with the client but has the naming conventions that you want incorporated. WSDL first coding can be done this way and is sometimes recommended because it provides the skeleton that you follow in creating and modifying to make it your own and fit your needs.

Solved by copying all the classed from the WSDL and made DataContracts of them instead, in this it's possible to define the NameSpace just like for the ServiceContract.
[DataContract(Namespace = "http://correctnamespace.com")]
public class Amount
{
Thanks for evryone who took timeto help me solve his.

WebServices fail because (400) Bad Request because of special character

Using Visual Studio 2008, I setup a client that uses Web Services.
It has nothing to do with buffer sizes (as that is a typical response, all appropriate sizes were increased).
I was using a List as the parameter of the Method.
After much experimentation, I used the System.Net.WebClient to manually create a Soap 1.1 and a Soap 1.2 request to test test the result.
using (var webCtx = new System.Net.WebClient())
{
webCtx.Headers.Add(System.Net.HttpRequestHeader.ContentType, "text/xml");
webCtx.Headers.Add("SOAPAction", "http://tempuri.org/HelloWorld");
var uri = new Uri("http://localhost:12345/MyProject/WebService.asmx");
MessageBox.Show(webCtx.UploadString(uri, xml));
}
Where the xml is a string variable of the xml with actual data.
The problem is when one of the fields has a special character. Here is the example of the message body of the xml.
<PocoClass>
<UnicodeString>123</UnicodeString>
</PocoClass>
If the value of UnicodeString was something simple (i.e. 123), but once the special character appeared, I got 400 Bad Request.
Now, I have found a Microsoft Knowledge Base Article describing the bug kb911276, which basically states, install a hot fix. That really isn't something that can be a solution to the problem, so I was wondering if there are any ideas of how to solve this problem?
Are the only solutions to write some sort of custom encoding/decoding or custom bindings to be implemented by the server and client? Are there any easier ideas?
Thanks
Edited:
The use of a List is not an issue as it is handled by VS. Here is a more complete (but still partial) contents of the soap message.
<HelloWorld xmlns="http://tempuri.org/">
<pocoList>
<PocoClass>
<UnicodeString>123</UnicodeString>
</PocoClass>
</pocoList>
</HelloWorld>

I had a similar problem with a webservice we had that users of our app run online account searches. I found a VS Feedback item about this, but it appears MS considers this behaviour by-design.
What we ended up doing was writing a method that replaced all characters that are not allowed when serializing to XML with question marks.
The allowed list was: 0x09, 0x0a, 0x0d, 0x20-0xd7ff, and 0xe000-0xfffd. Everything else, we turned to "?".
I guess if you can't do that, the data should be base64-encoded in transit to avoid this issue. Seems a bit odd to me, as it breaks the ability to losslessly route a call through a web service.

My concern is where you state that you are using a List as the parameter to a method. Web services don't directly support lists. You need to use an array as the parameter. Then internally you can convert it to a list using .ToList(). This may not be your issue directly!

That KB article was referring to unicode character sets within a request URL, not actual data being posted to the server.
That being said; i'd verify that your headers are well formed.
Also, if VS generated the client proxy for you; right click on the service reference and then on "Update Service Reference"
Just noticed one more thing; you said that you are passing in a list as a parameter; from the snippet of xml shown, that doesn't look like something that would be serialized from a list (by any of the .NET xml serializers); if you want to debug using the webclient approach; try verifying that the format of the xml is valid.

Where are you seeing ? In the raw XML or the serialized data? XML is defined to contain only human-readable characters and  is the XML entity for the unreadable ASCII Shift-Out character. If you're looking at the raw XML and it contains the XML entity code, that's allowed, but if you are looking at serialized data and your XML document contains raw control characters it is invalid and will be rejected.