XmlAnyElementAttribute problem on Compact Framework

  • Thread starter Thread starter Stefan Cuypers
  • Start date Start date
S

Stefan Cuypers

Hi,

I'm currently implementing a client layer for a web service we use for the
Compact Framework and am experiencing a problem with the
XmlAnyElementAttribute. When we use the code below to call the
GetEnvironments web method from the full .NET Framework everything works
fine, but when we use it on the Compact Framework it seems that the
arguments marked with the XmlAnyElementAttribute are ommitted in the SOAP
message (no error or exception is generated, the argument just isn't present
in the SOAP message). Does anyone have any idea what could be the cause of
this?
The return value of the function is also marked with the
XmlAnyElementAttribute and that one works fine.

The web service is defined in WSDL at
http://www.computerscuypers.be/wsdl/CCAppLogon.wsdl
Code to call the web service:
[System.Web.Services.WebServiceBindingAttribute(Name="CCAppLogonSoap",
Namespace="http://www.computerscuypers.be/CCAppManagement/CCAppLogon")]

internal class CCAppLogonWS :
System.Web.Services.Protocols.SoapHttpClientProtocol

{

public CCAppLogonWS(string url)

{

Url = url;

}

[System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://www.compu
terscuypers.be/CCAppManagement/CCAppLogon/GetEnvironments",

RequestNamespace="http://www.computerscuypers.be/CCAppManagement/CCAppLogon"
,

ResponseNamespace="http://www.computerscuypers.be/CCAppManagement/CCAppLogon
",

Use=System.Web.Services.Description.SoapBindingUse.Literal,

ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]

[return:
XmlAnyElement("environments",Namespace="http://www.computerscuypers.be/CCApp
Management")]

public XmlElement GetEnvironments(

[XmlAnyElement("logonParams","http://www.computerscuypers.be/CCAppManagement
")] XmlElement logonParams,

string cultureName)

{

object[] results = this.Invoke("GetEnvironments", new object[] {

logonParams,

cultureName});

return ((XmlElement)(results[0]));

}

....

regards,
Stefan Cuypers
 
I am trying to reproduce your problem.
Can you please post some sample client code that calls your WebService then
I can take a closer look at it.
Also how did you generate your proxy? You seem to be using a hand crafted
proxy. Is there any particular reason why you not using the proxy created
by Visual Studio?

Thanks.
 
I delved a bit into the code and found the problem. It seems to be a bug in
the System.Web.Services.Protocols.QNameContainer/ValueEnumerator class. My
main problem now is that I can't really figure out a workaround (apart form
a Microsoft hotfix). Any idea if we could get a fix for this in rather short
time (we're currently in the last phase of this project that should go into
production before the end of this year)?

Here's the problem :
Decompiled QNameContainer/ValueEnumarator class :
private class ValueEnumerator: IEnumerator, IEnumerable
{
private QNameContainer.ListElement[] m_elements;
private int m_count;
private int m_idx;

object IEnumerator.Current
{ get {return m_elements[m_idx - 1].Value;} }

internal ValueEnumerator(QNameContainer.ListElement[] elts, int count)
{
m_elements = elts;
m_count = count;
m_idx = -1;
}

bool IEnumerator.MoveNext()
{
m_idx++;
return m_idx == m_count;
}

void IEnumerator.Reset()
{
m_idx = -1;
}

IEnumerator IEnumerable.GetEnumerator()
{
return this;
}
}

When this enumerator is used (from
SoapMessageFormatter.serializeAnyElements) in my case it's constructor is
called with 1 element.
So m_count = 1 and m_idx = -1 after construction.
Then the foreach() construct calls MoveNext() :
m_idx++ -> m_idx becomes 0
return m_idx == m_count (0 == 1) -> returns false causing the foreach() loop
to end withouth ever processing element 1!!

BTW the Current property also seems a bit strange. After the first
MoveNext() m_idex equals 0, causing element [-1] to be called upon!

The reason we use our own handcrafted proxy has to do with our design cycle
and the use of special support classes that directly process the XML.
In our design cycle we first created the XSD's describing all elements, next
we designed the WSDL and then we went to implementation. This caused some
unsupported features to get included (e.g. extra properties on collection
parameters, which is not supported by XML serialisation).
We also created a set of wrapper objects for the XML that provide a lot more
functionality than just wrapping the XML and so we did not want to use the
automatically generated classes.

If you still need some sample code that calls the web service, I can try to
isolate a sample from our project next week. Please let me know if this is
still required?

regards,
Stefan
 
Stefan, this is a known issue which has been fixed in V2 of the compact
framework (which is currently in Beta).
However we are investigating possible V1 workarounds for you and will be
posting one shortly.

Thanks.
 
Mark,
Thanks for the info. Will the fix also be in CF SP3? The current beta of SP3
still seems to have the same problem.
Stefan
 
Hello Stefan,

We may have a possible work around that would require a change to the
proxy but the web services. Can you try removing the name and
namespace properties from the XmlAnyElementAttribute that decorates
the logonParams parameter and check if the server handle this message
correctly? So, in the proxy the logonParams parameter would only be
decorated with [XmlAnyElement()]. The rest of the method remains the
same. Let us know if this works.

Thanks.

// RDY
 
Hit the post message to early...

We may have a possible work around that would require a change to the
proxy but not the web services. Could you try removing the ElementName
and Namespace properties from the XmlAnyElementAttribute that
decorates the logonParams parameter and check if the server handle
this message correctly? So, in the proxy the logonParams parameter
would only be decorated with [XmlAnyElement()] instead of
[XmlAnyElement("logonParams","http://www.computerscuypers.be/CCAppManagement")].
The rest of the method remains the same. Let us know if this works.

Thanks.

// RDY
 
The fix for this issue will be in SP3 which should be available within a
month.
Thanks.
 
Mark,

Is there already a release date for the Compact Framework SP3? We're now
waiting for this fix to continue with our project.

Stefan.
 
Stefan I don't have the answer to your direct question but I can share some
positive news

Last year (November), there was a QFE release for Platform Builder that
upgraded the NETCF:
http://www.danielmoth.com/Blog/2004/11/qfe-42-cf-update.html

If you look at the fix list, it is a superset of the one published as the
SP3 Beta (there is one item that is on the Beta list and is not on the QFE
list but I have verified that it is also fixed so it must be a documentation
omission). So for all intent and purposes this is SP3 (*pending official
MSFT confirmation*).

I have confirmed that your issue is fixed (I run your repro and can see
logonParams). So you are back to waiting for the enduser/developer redist if
the QFE is not good to you.

Cheers
Daniel
 
Back
Top