Hi Atsushi, mån 2007-02-05 klockan 15:14 +0900 skrev Atsushi Eno: > Hi Daniel, > > Daniel Lundqvist wrote: > > The issue here is that it always sends the oid and parentoid field > > regardless of value of <field>Specified. > > I got a patch (against SVN) for it, don't know if it's correct but > > solves the problem for me. So now it only sends oid and parentoid when > > <field>Specified is set to true. This was tested with 1.1.17.1 but the > > problem is in SVN as well from what I can see. > > Oh, cool. Can you please share the patch so that it could be fixed?
Of course, thought I attached it but I'll reattach it. The problem is that XmlTypeMapMember::CheckOptionalValueType is never called and thus the OPTIONAL bit in its flags field is never set (Which is then checked in XmlSerializationWriterInterpreter::MemberHasValue). There are some other places (I think) that XmlTypeMapMember is instanciated but I didn't add the call there, so this patch only fixes my problem. Perhaps this call should be placed in a more appropiate place, but I don't speak the XML/WS stack fluently enough to find where. > > > 2) When using wsdl2 from latest release of Mono I have the following issues: > > 1) When using properties for member access, and field is the same name > > as a keyword it don't prefix the property name with @. > > Hmm, it would be nice if you file a bug for it. It is kind of corner > case, but fixing it would be nicer. Will do. Discovered another problem of the same kind. The parser that is generated for the WS also have the same problem with types that is named after keywords and object, so when Mono tries to compile it it encounters a couple of syntax errors. > > > 2) It seems to generate each service binding twice. One with the normal > > name and another with <name>1. I.i > > [System.Web.Services.WebServiceBinding(Name="packetfront_becs", > > Namespace="urn:packetfront_becs")] > > [System.Diagnostics.DebuggerStepThroughAttribute()] > > [System.ComponentModel.DesignerCategoryAttribute("code")] > > public class packetfront_becs : > > System.Web.Services.Protocols.SoapHttpClientProtocol { > > <snip> > > } > > > > [System.Web.Services.WebServiceBinding(Name="packetfront_becs", > > Namespace="urn:packetfront_becs")] > > [System.Diagnostics.DebuggerStepThroughAttribute()] > > [System.ComponentModel.DesignerCategoryAttribute("code")] > > public class packetfront_becs1 : > > System.Web.Services.Protocols.SoapHttpClientProtocol { > > <snip> > > } > > Do you have test case for this as well? I tried it (from svn) but > it didn't happen. Though I remember this kind of duplicate results > from those days I was working on Sys.Web.Services in my private > branch. It was because of target protocol unawareness on processing > bindings. Hmm.. ok. Do this mean that there is some error in the WSDL file? I can send our WSDL file in private to you if you want to investigate it. Btw is there a way to have the WS stack reuse same WebRequest object for the duration of the program? As it is now it creates a new for WebRequest now and then (after a short while of inactivity it seems) and this a new TCP connection. I would like it to use HTTP/1.1 Keep-Alive to cut down traffic and TCP connections (since my software is a fairly long running CLI program that does 50k-100k SOAP calls). I tried overriding GetWebRequest(Uri) on the generated WS proxy code to return a singleton WebRequest but that only resulting in using a disposed object after a short while. Thanks in advance. -- daniel
Index: SoapReflectionImporter.cs =================================================================== --- SoapReflectionImporter.cs (revision 72075) +++ SoapReflectionImporter.cs (arbetskopia) @@ -224,7 +224,9 @@ ICollection members = GetReflectionMembers (type); foreach (XmlReflectionMember rmember in members) { if (rmember.SoapAttributes.SoapIgnore) continue; - classMap.AddMember (CreateMapMember (rmember, defaultNamespace)); + XmlTypeMapMember tmember = CreateMapMember (rmember, defaultNamespace); + tmember.CheckOptionalValueType(type); + classMap.AddMember (tmember); } // Import included classes
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list