I don't quite understand the problem here.
The XmlAttribute and other attributes you can apply to classes, will affect
the behavior of .NET's XML serialization. XML Serialization is used when
you are just doing conversions (to and from XML) , which is to say direct
serialization. But it also is used in .NET for webservices, implicitly.
The resulting XML stream in your SOAP requests or responses, should be SOAP
compliant, with or without your attributes. It's still SOAP. It might be
shaped differently, but it's SOAP. You say, it's not the "normal SOAP-y
xml" you expect, but what is not normal about it, precisely? Does it not
work? Can it not be de-serialized on the other end of the webservice? Is
it an aesthetic thing?
If you really want to serialize the same class in 2 different manners ,
there are ways to go. Two of them I can think of are:
1. define an adapter or bridge class. It is a companion to the original
class, and can take a different set of XML serialization attributes.
2. specify the XML attributes you want for webservices on the class, and
then specify attribute overrides for when you do direct serialization.
-Dino
"Angelos Karantzalis" <ak**********@yahoo.com> wrote in message
news:eR*************@TK2MSFTNGP15.phx.gbl...
Hi y'all,
we're using a bunch of classes in a project, that we wanted to convert
to-from xml easily. So, we defined XmlAttribute annotations for our class
members and all worked fine. The Xml stream came from an external source
with a custom xml schema, so we had no alternative.
However, along the way we came to the point that we must expose those
classes as return types for a web service. Returning an instance of a
class
through the web service though, we noticed that the resulting xml is not
the
normal SOAP-y xml we expected, but rather our class, serialized with the
annotations we'd put in it beforehand.
Can we 'override' that serialization behavior and have the web service
framework do what it would normally do and serialize the class in the
expected way ?
Cheers,
Angel
O:]