[Mono-dev] WS stack.

[Daniel Lundqvist]

Hey again :)

ons 2007-02-07 klockan 20:51 +0900 skrev Atsushi Eno:
> Hi Daniel,
> 
> Daniel Lundqvist wrote:
> > 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).
> 
> Thanks :) However, now I tried your patch but it does not seem to
> fix the issue. Do you have actual case that the patch indeed fix
> the issue? I attached what I tried.

Weird. I've redone my tests with the 1.2.3 release. With a stock
System.Xml.dll it have the problem but with a patched (with the patch I
sent earlier) it don't.

> > 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.
> 
> If your patch does not fix the case that I attached, then yes it is
> likely to happen. I'd wait for your case and try to fix it.

Now I think I see one issue. Since you are using WebService and
WebMethod attributes perhaps they are hitting the other path that is
calling CreateMapMember(), in ImportMembersMapping in either
XmlReflectionImport.cs or SoapReflectionImport.cs (depends on using
literal encoding or not).

After some more investigation that seems to be the case. From what I can
see the enclosing type is not available at that point (which is needed
to call XmlTypeMapMember::CheckOptionalValueType).

> >>>  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.
> 
> If you mean what I've experienced, then no, it was bugs in my code
> that it produced proxy classes for both SOAP 1.1 and 1.2 profiles.
> 
> If you can send me the problematic WSDL, I'll check it :)

Thanks. I'll send that in a separate mail.

Thanks for taking your time with this.

-- 
daniel