Problem controlling SOAP (de)serialization

[Martijn Saly]

I have a class that looks like this (simplified):

public class Field {
public string Name;
public string Value;
}

I'm creating a webmethod that has this class as an argument, and the
following SOAP fragment for that is expected:

<Field>
<Name>string</Name>
<Value>string</Value>
</Field>

I want to make this (de)serialized as:

<Field Name="string">string</Field>

This would, of course eat up less bandwidth, and it looks more logical
for a little name/value-class. I've tried adding [XmlAttribute("Name")]
to the Name property, and that works perfectly. So I get this:

<Field Name="string">
<Value>string</Value>
</Field>

Which looks even more silly, I think. So how do I get the aforementioned
way of (de)serialization? Any thoughts/ideas?

 

[Josh Twist]

You need to decorate your class with the XmlAttributeAttribute:

using System.Xml.Serialization;

public class Field {
[XmlAttribute()]
public string Name;
public string Value;
}

Josh
http://www.thejoyofcode.com/

 

[Martijn Saly]

You need to decorate your class with the XmlAttributeAttribute:

using System.Xml.Serialization;

public class Field {
[XmlAttribute()]
public string Name;
public string Value;
}

Josh
http://www.thejoyofcode.com/

Like I said, that'll give me half of what I want:

<Field Name="string">
<Value>string</Value>
</Field>

I can apply XmlAttribute to the Value property as well, but that's not what
I want:

<Field Name="string" Value="string"/>

Because I want this:

<Field Name="string">string</Value>

 

[Josh Twist]

Oops sorry - Martijn, mustn't have finnished reading your post
properly! My apologies:

public class Field {
[XmlAttribute()]
public string Name;

[XmlText()]
public string Value;
}

 

[Martijn Saly]

Oops sorry - Martijn, mustn't have finnished reading your post
properly! My apologies:

public class Field {
[XmlAttribute()]
public string Name;

[XmlText()]
public string Value;
}

Thanks
That seems to work perfectly, I didn't know it was that easy

So the response and request of my webservice calls are now properly
(de)serialized, but there's one little thingy left... the HTML pages
that .NET generates for a webservice indicate that the following XML for
my class will/should be in the response/request:

<Field Name="string" />

That might confuse webservice consumers, as this is not correct,
according to the actual output of a webmethod that returns an instance
of my class...

 

[Josh Twist]

I'm not sure there is much you can do about it but your service
consumers shouldn't pay too much attention tot the asmx help page
anyway. It's the WSDL that matters.

You could customise the the DefaultWsdlHelpGenerator page or remove it
altogether (http://www.15seconds.com/issue/040609.htm)?

Josh
http://www.thejoyofcode.com/

 

[Martijn Saly]

I'm not sure there is much you can do about it but your service
consumers shouldn't pay too much attention tot the asmx help page
anyway. It's the WSDL that matters.

You could customise the the DefaultWsdlHelpGenerator page or remove it
altogether (http://www.15seconds.com/issue/040609.htm)?

Josh
http://www.thejoyofcode.com/

You're right, but if the client doesn't support WSDL (such as an old
version of Visual Objects, for example), the programmer hardcodes the
SOAP message into the source code (arg! but unfortunately it happens)
and he'll probably want to take a look at the help page, rather than
examining the whole WSDL

Anyway, thanks for all the info, I'll take a look at customizing the
DefaultWsdlHelpGenerator.

 

[Josh Twist]

I see your point - but I'd recommend you publish your own documentation
in that case because the help file only goes 'one level deep' anyway.
So if you have any real depth to your classes most of the detail would
be missing.

Good luck!

 

[Josh Twist]

I see your point - but I'd recommend you publish your own documentation
in that case because the help file only goes 'one level deep' anyway.
So if you have any real depth to your classes most of the detail would
be missing.

Good luck!