XmlNode in Generated Typed Class

What wrong with adding WSDL url as web reference?

I guess the real question is...

If we have hierarchical document schemas, defined in separate files, what's the best way to add the component documents to the enveloping document in CSharp or VB.NET code?

I really want to use a strongly typed data type (the generated class definition) because is makes the client interface so easy: create an instance and set the values.

In this case, setting the value of a subelement seems to be difficult or I'm missing something.

Maybe the case where the subelement can be one of several types is more difficult than if it were strongly typed itself?

There are two XSchema definition files from a vendor that describe the XML content for a single parameter in a SOAP/RPC web service. One XSD describes a wrapper, let's call it A, for the other, B, (I didn't design these) and the wrapper indicates a sequence of <xs:any/> elements where XML defined by the second schema should be.

The goal is to have a reasonably simple object to use to build the string parameter for the SOAP/RPC call.

A contains:
<xs:complexType name="body" mixed=true>
<xs:sequence>
<xs:any namespace="http://temp.uri/B" processContents=skip minOccurs="0" maxOccurs="unbounded"/>
<xs:sequence>
</xs:complexType>

B contains a complex set of many elements with the outermost element <document>.

So, I would expect two classes A.vb and B.vb as a result of running XSD.EXE. We get those, but in A.vb, the reference to B seems to be as an XMLNode rather than an object of type B.

What we get in A.vb is:
Public Class body
'<remarks/>
<System.Xml.Serialization.XmlTextAttribute(), _
System.Xml.Serialization.XmlAnyElementAttribute()> _
Public Any() As System.Xml.XmlNode
End Class
So we cannot write something like:

Dim a As A = new A
a.body.document.somevalue = "text value here"

In order to serialize a complete object A with B as a part of it, it seems that we have to serialize A with no B object in it, then find the body node and then serialize a separate object B into that node's innerXML. That seems too difficult.

It appears that XSDObjectGen does something similar but we found a way to create a strongly typed reference using a schema derived from an actual, though incomplete, message using XsdInference at gotdotnet. I copied the reference to B generated by the latter technique into the A class generated by the latter and we have a working solution.

This is what we get in A.vb for the reference to the body element when we infer the schema from a message:

Public Class body

'*********************** document element ***********************
<XmlElement(Type:=GetType(b.document), ElementName:="document", IsNullable:=False, Form:=XmlSchemaForm.Qualified, Namespace:="http://vendorUri/B"), _
EditorBrowsable(EditorBrowsableState.Advanced)> _
Public __document As b.document

<XmlIgnore()> _
Public Property document() As csr.document
Get
If __document Is Nothing Then __document = New csr.document
document = __document
End Get
Set(ByVal Value As csr.document)
__document = Value
End Set
End Property

'*********************** Constructor ***********************
Public Sub New()
End Sub
End Class
Now, I can write something like the above sample and I get a complete object out of it and serializing A includes serializing B.

XSD and XSDObjectGen should yield a strongly typed reference to Class B within the definition for Class A given the two XSD files.

--Peter

Yes. It's funny that it can be easily set by making a reference to the second class and that inferring the XSD from a sample message, though incomplete, correctly creates two classes with the appropriate reference. I guess when generating the classes from each separate file, there are no smarts in the tools to look for the additional class file or xsd and work it in.

The good news, is that we can safely assume one document element in each message. After reviewing the B.xsd, it looks like it could be any number of elements or subelements given the hiearchy (or lack thereof) but I don't think we'll ever see more than one.

The WSDL does not expose the structure of the content of the SOAP/RPC string parameter so updating WSDL is just not helpful.

The vendor on this also requires particular namespace aliases to appear on each element, rather than seeing what is defined above so I think its a brain-dead implementation on the vendor side anyway.

I don't know if these problems are common for Axis implementations or if it is just this vendor's software team.

We've gotten little documentation except for the wsdl and the xsd files and everything seems very loose so we'll have to go with the flow.

Thanks for your comments.

--Peter