«

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?

--
Thanks,

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/

Josh Twist wrote:
> 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>

--
Thanks,

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;
}

Josh Twist wrote:
> 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...

--
Thanks,

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/

Josh Twist wrote:
> 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.

--
Thanks,

Martijn Saly

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!

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!