[Mono-bugs] [Bug 74760][Nor] New - Mono does not mangle SOAP-serialized names like MS.Net

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by ravitch@nrtc.northrop.com.

http://bugzilla.ximian.com/show_bug.cgi?id=74760

--- shadow/74760	2005-04-28 16:31:19.000000000 -0400
+++ shadow/74760.tmp.1519	2005-04-28 16:31:19.000000000 -0400
@@ -0,0 +1,83 @@
+Bug#: 74760
+Product: Mono: Class Libraries
+Version: 1.1
+OS: All
+OS Details: Fedora Core 3 and Windows 2000
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Normal
+Component: System
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: ravitch@nrtc.northrop.com               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Mono does not mangle SOAP-serialized names like MS.Net
+
+Description of Problem:
+
+MS.Net mangles the names of private inherited fields when an object is
+serialized into SOAP.  Mono does not.
+
+MS.Net prepends the name of the base class that declared the field
+to the name of the field, using "_x002B_" as a delimiter.  There is also
+some escaping that goes on using "_x005F_".
+
+Additionally, Mono does not support SoapFieldAttribute.XmlFieldName.
+(Actually, it's there - but the serializer ignores it.)  Because it was
+convenient, I gratuitously added support for it in my patch.  (I apologize
+if that should have been filed as a seperate bug.)
+
+Steps to reproduce the problem:
+
+1. Download and build sample code (attached) on a client machine (I used
+   a Linux box).  The Makefile should show the necessary steps, but it's
+   pretty straightforward.
+2. Edit client.config so that it points to your server machine.  Use a
+   Windows box for the server.
+3. Do step (1), but on your server.
+4. Run server.exe on the server under MS.Net.
+5. Run client.exe on the client under Mono.
+
+Actual Results:
+
+---- BEGIN CLIENT OUTPUT ----
+Client: Creating object
+Building up the container
+Sending over the container
+
+Unhandled Exception: System.Net.WebException: The remote server returned an
+error: (500) Internal Server Error.
+in <0x003c2> System.Net.HttpWebRequest:CheckFinalStatus
+(System.Net.WebAsyncResult result)
+in (wrapper remoting-invoke-with-check)
+System.Net.HttpWebRequest:CheckFinalStatus (System.Net.WebAsyncResult)
+in <0x000f2> System.Net.HttpWebRequest:EndGetResponse (IAsyncResult
+asyncResult)in <0x0005f> System.Net.HttpWebRequest:GetResponse ()
+in <0x0003b>
+System.Runtime.Remoting.Channels.Http.HttpClientTransportSink:SendAndRecieve
+(System.Net.HttpWebRequest httpRequest, ITransportHeaders responseHeaders,
+System.IO.Stream responseStream)
+---- END CLIENT OUTPUT ----
+
+Expected Results:
+
+---- BEGIN CLIENT OUTPUT ----
+Client: Creating object
+Building up the container
+Sending over the container
+Client: ALL DONE!
+---- END CLIENT OUTPUT ----
+
+How often does this happen? 
+
+Every time.
+
+Additional Information:
+
+I implemented a patch (attached) that appears to fix the situation.  My
+GetFieldName function had to go somewhere, so I put it in SoapReader.cs.
+It could just as well have gone into SoapWriter.cs.  I'm not sure which
+is more correct - both are patched to use it.