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
> Hi y'all,
>
[quoted text clipped - 18 lines]
> Angel
> O:]
Angelos Karantzalis - 23 Feb 2005 08:15 GMT
Thank you very much Dino. Those were the ways I was thinkin' of as well.
The problem arised from the client, where it is an html page with Microsofts
Web Service behavior running on it, which doesn't like my XML Serialization
format :] At this point, we at a solution where we parse the XML returned
from the web service & create JScript object graphs semi-automatically, but
we're exploring our server-side options as well.
Cheers,
Angel
O:]
> I don't quite understand the problem here.
>
[quoted text clipped - 41 lines]
> > Angel
> > O:]