Hello Rgliane,
Regarding on the CR(X0D) LF(x0A) characters issue, it is actually due to
the response conversion(in the client proxy's internal code) against the
string data in soap response message. Based on my tracing, both the 0D
and 0A chars are correctly sent back to the client-side, however, it is in
the SoapHttpClientProtocol(base class of client proxy)'s code, when it read
the content from the response stream, for string value, it will filtered
the "0A" char. I haven't got the exact code logic, based on reflector's
diassembled code, it is during the "ReadResponse" method.
So far I think for string type parameter or return value, it will force
this normalizing rules on the control character, if you do need to get the
exact character list, I suggest you consider transfer the string as byte
array (encoding it before transfer and decode it after received). e.g.
=========================
[WebMethod]
public byte[] GetBinaryData()
{
string str = string.Empty;
str = "abc\r\n";
return Encoding.Unicode.GetBytes(str);
}
=====================
=======client code==========
byte[] bytes = proxy.GetBinaryData();
string str = Encoding.Unicode.GetString(bytes);
Console.WriteLine(str.Length);
=====================
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
rgliane - 21 Feb 2007 23:43 GMT
Using a byte array is what I came up with also before my re-post of the
question. It works...I'm just surprised that the proxy was written to drop
the character. I could possibly understand if it was written for a UNIX
system where the LF is sufficient to designate EOL but the proxy code is
specifically for Windows. Weird...
Is there any way to configure the proxy creation so that it stops doing
this? Or if not now, can this be an enhancement request?
> Hello Rgliane,
>
[quoted text clipped - 67 lines]
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
Steven Cheng[MSFT] - 26 Feb 2007 07:59 GMT
Thanks for your followup Rgliane,
So far I haven't found any better solution. I'll help you consult some
other ASMX webservice experts to see whether there is anything else we can
do here to workaround the issue.
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.
Steven Cheng[MSFT] - 27 Feb 2007 08:44 GMT
Hello Rgliane,
I have got some further information on this issue. For the client-side
proxy, we can override its "GetReaderForMessage" method get the underlying
XMLReader and than turn off its "Normalization". You can put the overrdie
method in a separate partial class file(so that it won't be overwritten
when update the proxy):
===============
public partial class Service :
System.Web.Services.Protocols.SoapHttpClientProtocol
{
protected override System.Xml.XmlReader
GetReaderForMessage(SoapClientMessage message, int bufferSize)
{
XmlTextReader reader =
(XmlTextReader)base.GetReaderForMessage(message, bufferSize);
reader.Normalization = false;
return reader;
}
==============
Also, as some other WS engineers has pointed, this string normalization is
conform to the XML specification, therefore, if you do the change, it will
only work for your particular client, and other webservice proxy(such as
java based) will still do this string normaliation, so this behavior is not
dedicated to .net framework implementation.
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.
rgliane - 27 Feb 2007 14:26 GMT
This is exactly what I need! Thanks for the continued effort.
As for it being per the XML specification...just further evidence why I
dislike stuff out of a committee ;-)
> Hello Rgliane,
>
[quoted text clipped - 34 lines]
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
Steven Cheng[MSFT] - 28 Feb 2007 00:41 GMT
You're welcome !
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead