Serialization with XmlSerializer: how to set the XML root node to something different from <ArrayOfClassname>????

[Bob Rock]

Hello,

when serializing an array of elements of a class Classname using
XmlSerializer.Serialize() I get an XML like the following:

<?xml version="1.0">
<ArrayOfClassname>
.......
.......
</ArrayOfClassname>

I'd like to be able to set the XML root node to something different from
<ArrayOfClassname> .... for example something like <Classnames>.
As an alternative when deserilizing an XML such as the following:

<?xml version="1.0">
<Classnames>
.......
.......
</Classnames>

I'd like to be able to "load" it into an array of objects of class Classname
(at the moment when making such an attempt I get an obvious exception
stating "<Classnames> was not expected").
Bob Rock

[Dino Chiesa [Microsoft]]

XmlArrayAttribute

see reference:
http://msdn.microsoft.com/library/en...ClassTopic.asp

and guide:
http://msdn.microsoft.com/library/en...attributes.asp

-Dino
ps: no need to cross-post
"Bob Rock" <no***************************@hotmail.com> wrote in message
news:O3*************@tk2msftngp13.phx.gbl...

Hello,

when serializing an array of elements of a class Classname using
XmlSerializer.Serialize() I get an XML like the following:

<?xml version="1.0">
<ArrayOfClassname>
......
......
</ArrayOfClassname>

I'd like to be able to set the XML root node to something different from
<ArrayOfClassname> .... for example something like <Classnames>.
As an alternative when deserilizing an XML such as the following:

<?xml version="1.0">
<Classnames>
......
......
</Classnames>

I'd like to be able to "load" it into an array of objects of class Classname (at the moment when making such an attempt I get an obvious exception
stating "<Classnames> was not expected").
Bob Rock

[Dino Chiesa [Microsoft]]

XmlArrayAttribute

see reference:
http://msdn.microsoft.com/library/en...ClassTopic.asp

and guide:
http://msdn.microsoft.com/library/en...attributes.asp

-Dino
ps: no need to cross-post
"Bob Rock" <no***************************@hotmail.com> wrote in message
news:O3*************@tk2msftngp13.phx.gbl...

Hello,

when serializing an array of elements of a class Classname using
XmlSerializer.Serialize() I get an XML like the following:

<?xml version="1.0">
<ArrayOfClassname>
......
......
</ArrayOfClassname>

I'd like to be able to set the XML root node to something different from
<ArrayOfClassname> .... for example something like <Classnames>.
As an alternative when deserilizing an XML such as the following:

<?xml version="1.0">
<Classnames>
......
......
</Classnames>

I'd like to be able to "load" it into an array of objects of class Classname (at the moment when making such an attempt I get an obvious exception
stating "<Classnames> was not expected").
Bob Rock

[Bob Rock]

"Dino Chiesa [Microsoft]" <di****@online.microsoft.com> wrote in message
news:uz**************@TK2MSFTNGP10.phx.gbl...

XmlArrayAttribute

see reference:
http://msdn.microsoft.com/library/en...ClassTopic.asp
and guide:
http://msdn.microsoft.com/library/en...attributes.asp
-Dino
ps: no need to cross-post

Dino,

I'm using Xmlserializer not implicitly within a web method but explicitly
within my code. So the question is, how do I apply the XmlArrayAttribute????
From the documentation is seems that this *should* be possible, but how???

Sorry for the cross-posting, but it is done only in the hope that more
people may read (and hopefully answer) my post.

Grazie mille.

Ciao,
Bob Rock

[Bob Rock]

"Dino Chiesa [Microsoft]" <di****@online.microsoft.com> wrote in message
news:uz**************@TK2MSFTNGP10.phx.gbl...

XmlArrayAttribute

see reference:
http://msdn.microsoft.com/library/en...ClassTopic.asp
and guide:
http://msdn.microsoft.com/library/en...attributes.asp
-Dino
ps: no need to cross-post

Dino,

I'm using Xmlserializer not implicitly within a web method but explicitly
within my code. So the question is, how do I apply the XmlArrayAttribute????
From the documentation is seems that this *should* be possible, but how???

Sorry for the cross-posting, but it is done only in the hope that more
people may read (and hopefully answer) my post.

Grazie mille.

Ciao,
Bob Rock

[Mickey Williams]

Maybe not exactly what you want, but you can get close like this:

public class Foo
{
ArrayList _classNames = new ArrayList();
[XmlArray("ClassNames"), XmlArrayItem("ClassName")]
public string[] ClassNames
{
get { return (string[])_classNames.ToArray(typeof(string)); }
set {_classNames = new ArrayList(value);}
}
}

Construct and serialize a Foo like this:

string[] names = new string[]{"f", "g", "h"};
Foo f = new Foo();
f.ClassNames = names;
Console.WriteLine(SerializeThingToXmlString(f));
Where the helper method is:

static string SerializeThingToXmlString(object thing)
{
StringWriter stringWriter = new StringWriter();
XmlSerializer serializer = new XmlSerializer(thing.GetType());
serializer.Serialize(stringWriter, thing);
return stringWriter.ToString();
}

--
Mickey Williams
Author, "Microsoft Visual C# .NET Core Reference", MS Press
www.servergeek.com/blogs/mickey

[Mickey Williams]

Maybe not exactly what you want, but you can get close like this:

public class Foo
{
ArrayList _classNames = new ArrayList();
[XmlArray("ClassNames"), XmlArrayItem("ClassName")]
public string[] ClassNames
{
get { return (string[])_classNames.ToArray(typeof(string)); }
set {_classNames = new ArrayList(value);}
}
}

Construct and serialize a Foo like this:

string[] names = new string[]{"f", "g", "h"};
Foo f = new Foo();
f.ClassNames = names;
Console.WriteLine(SerializeThingToXmlString(f));
Where the helper method is:

static string SerializeThingToXmlString(object thing)
{
StringWriter stringWriter = new StringWriter();
XmlSerializer serializer = new XmlSerializer(thing.GetType());
serializer.Serialize(stringWriter, thing);
return stringWriter.ToString();
}

--
Mickey Williams
Author, "Microsoft Visual C# .NET Core Reference", MS Press
www.servergeek.com/blogs/mickey

[Bob Rock]

> Maybe not exactly what you want, but you can get close like this:

public class Foo
{
ArrayList _classNames = new ArrayList();
[XmlArray("ClassNames"), XmlArrayItem("ClassName")]
public string[] ClassNames
{
get { return (string[])_classNames.ToArray(typeof(string)); }
set {_classNames = new ArrayList(value);}
}
}

Construct and serialize a Foo like this:

string[] names = new string[]{"f", "g", "h"};
Foo f = new Foo();
f.ClassNames = names;
Console.WriteLine(SerializeThingToXmlString(f));
Where the helper method is:

static string SerializeThingToXmlString(object thing)
{
StringWriter stringWriter = new StringWriter();
XmlSerializer serializer = new XmlSerializer(thing.GetType());
serializer.Serialize(stringWriter, thing);
return stringWriter.ToString();
}

--
Mickey Williams
Author, "Microsoft Visual C# .NET Core Reference", MS Press
www.servergeek.com/blogs/mickey

Ahhh, so that is the way you can use the XmlArrayAttribute and
XmlArrayItemAttribute on something that is not a field!!!
Is it possible to use it on methods returning arrays???

I've also seen that there is a way of setting the root node element to
whatever one wants using the XmlSerializer(Type, XmlRootAttribute)
constructor. Unfortunately when deserializing I need to change the root node
element to <ArrayOfClassname> as the XmlSerializer expects to avoid the
exception.
Bob Rock

[Bob Rock]

> Maybe not exactly what you want, but you can get close like this:

public class Foo
{
ArrayList _classNames = new ArrayList();
[XmlArray("ClassNames"), XmlArrayItem("ClassName")]
public string[] ClassNames
{
get { return (string[])_classNames.ToArray(typeof(string)); }
set {_classNames = new ArrayList(value);}
}
}

Construct and serialize a Foo like this:

string[] names = new string[]{"f", "g", "h"};
Foo f = new Foo();
f.ClassNames = names;
Console.WriteLine(SerializeThingToXmlString(f));
Where the helper method is:

static string SerializeThingToXmlString(object thing)
{
StringWriter stringWriter = new StringWriter();
XmlSerializer serializer = new XmlSerializer(thing.GetType());
serializer.Serialize(stringWriter, thing);
return stringWriter.ToString();
}

--
Mickey Williams
Author, "Microsoft Visual C# .NET Core Reference", MS Press
www.servergeek.com/blogs/mickey

Ahhh, so that is the way you can use the XmlArrayAttribute and
XmlArrayItemAttribute on something that is not a field!!!
Is it possible to use it on methods returning arrays???

I've also seen that there is a way of setting the root node element to
whatever one wants using the XmlSerializer(Type, XmlRootAttribute)
constructor. Unfortunately when deserializing I need to change the root node
element to <ArrayOfClassname> as the XmlSerializer expects to avoid the
exception.
Bob Rock

[Dino Chiesa [Microsoft]]

> Ahhh, so that is the way you can use the XmlArrayAttribute and

XmlArrayItemAttribute on something that is not a field!!!
Is it possible to use it on methods returning arrays???
Methods can return instances of Foo. Those instances of Foo will behave as
indicated by the attributes on Foo.
If your method returns an array, then the attributes that apply are those on
the base type.
So if it is an array of Foo that is being returned, then the attributes on
the Foo definition will apply to the elements of the array.

I believe it is not possible to effectively attribute arrays if they are not
serialized as members of classes. In other words, if it is a local variable
and you want to serialize it, I believe the attributes do not apply. Also
if the array is a member variable and you do not serialize the entire class,
then I believe the attributes do not apply.
I've also seen that there is a way of setting the root node element to
whatever one wants using the XmlSerializer(Type, XmlRootAttribute)
constructor. Unfortunately when deserializing I need to change the root node element to <ArrayOfClassname> as the XmlSerializer expects to avoid the
exception.
Yes this should work, but I don't understand what the problem is on
de-serializing. If you are using the same kind of XmlSerializer
(constructed with the XmlRootAttribute), then the string or stream with the
modified root node should de-serialize just fine. eg

XmlRootAttribute xRoot = new XmlRootAttribute();
xRoot.Namespace = "urn:www.example.org";
xRoot.ElementName = "Bunch";

s= new XmlSerializer(typeof(Fred[]), xRoot);
Fred[] f= {.....};

// serialize to a string:
StringWriter sw = new StringWriter();
s.Serialize( sw, f );
string serializedXml = sw.ToString(); // will give you a modified
root element name

// now de-serialize
StringReader sr= new StringReader(serializedXml);
Fred[] f2= (Fred[]) s.Deserialize(new System.Xml.XmlTextReader(sr));

Sorry for the cross-posting, but it is done only in the hope that more

people may read (and hopefully answer) my post.

Uh huh. I hate to be a stick in the mud about the cross posting, but 1st, I
can't help it, it's my nature; and 2nd, this seems like a really really
basic case. You are asking specifically about xml serialization, and there
is a specific group for xml serialization. A perfect match! Posting more
widely doesn't make sense to me. Yes, more people see it. But not more
people who care, or who will have anything to contribute. You could also
ask xml serialization questions to people you meet in the subway on the way
to work, or at church, or in the stands at the ballgame, but I doubt you'll
have much success there either.

Imagine if everyone followed your policy. Every question on every topic
would get asked on every group. Would that work? The different groups are
set up to raise the signal-to-noise ratio. If only works if the
participants follow the conventions.

Sometimes cross-posts make sense because it is not clear what area the
question would fall under. 2 groups is reasonable. 3 is about the limit.
4 is egregious.

I am not making any of this up. This is just standard netiquette.
http://www.google.com/search?hl=en&n...+cross+posting
-D
"Bob Rock" <no***************************@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

Maybe not exactly what you want, but you can get close like this:

public class Foo
{
ArrayList _classNames = new ArrayList();
[XmlArray("ClassNames"), XmlArrayItem("ClassName")]
public string[] ClassNames
{
get { return (string[])_classNames.ToArray(typeof(string)); }
set {_classNames = new ArrayList(value);}
}
}

Construct and serialize a Foo like this:

string[] names = new string[]{"f", "g", "h"};
Foo f = new Foo();
f.ClassNames = names;
Console.WriteLine(SerializeThingToXmlString(f));
Where the helper method is:

static string SerializeThingToXmlString(object thing)
{
StringWriter stringWriter = new StringWriter();
XmlSerializer serializer = new XmlSerializer(thing.GetType());
serializer.Serialize(stringWriter, thing);
return stringWriter.ToString();
}

--
Mickey Williams
Author, "Microsoft Visual C# .NET Core Reference", MS Press
www.servergeek.com/blogs/mickey

[Dino Chiesa [Microsoft]]

> Ahhh, so that is the way you can use the XmlArrayAttribute and

XmlArrayItemAttribute on something that is not a field!!!
Is it possible to use it on methods returning arrays???
Methods can return instances of Foo. Those instances of Foo will behave as
indicated by the attributes on Foo.
If your method returns an array, then the attributes that apply are those on
the base type.
So if it is an array of Foo that is being returned, then the attributes on
the Foo definition will apply to the elements of the array.

I believe it is not possible to effectively attribute arrays if they are not
serialized as members of classes. In other words, if it is a local variable
and you want to serialize it, I believe the attributes do not apply. Also
if the array is a member variable and you do not serialize the entire class,
then I believe the attributes do not apply.
I've also seen that there is a way of setting the root node element to
whatever one wants using the XmlSerializer(Type, XmlRootAttribute)
constructor. Unfortunately when deserializing I need to change the root node element to <ArrayOfClassname> as the XmlSerializer expects to avoid the
exception.
Yes this should work, but I don't understand what the problem is on
de-serializing. If you are using the same kind of XmlSerializer
(constructed with the XmlRootAttribute), then the string or stream with the
modified root node should de-serialize just fine. eg

XmlRootAttribute xRoot = new XmlRootAttribute();
xRoot.Namespace = "urn:www.example.org";
xRoot.ElementName = "Bunch";

s= new XmlSerializer(typeof(Fred[]), xRoot);
Fred[] f= {.....};

// serialize to a string:
StringWriter sw = new StringWriter();
s.Serialize( sw, f );
string serializedXml = sw.ToString(); // will give you a modified
root element name

// now de-serialize
StringReader sr= new StringReader(serializedXml);
Fred[] f2= (Fred[]) s.Deserialize(new System.Xml.XmlTextReader(sr));

Sorry for the cross-posting, but it is done only in the hope that more

people may read (and hopefully answer) my post.

Uh huh. I hate to be a stick in the mud about the cross posting, but 1st, I
can't help it, it's my nature; and 2nd, this seems like a really really
basic case. You are asking specifically about xml serialization, and there
is a specific group for xml serialization. A perfect match! Posting more
widely doesn't make sense to me. Yes, more people see it. But not more
people who care, or who will have anything to contribute. You could also
ask xml serialization questions to people you meet in the subway on the way
to work, or at church, or in the stands at the ballgame, but I doubt you'll
have much success there either.

Imagine if everyone followed your policy. Every question on every topic
would get asked on every group. Would that work? The different groups are
set up to raise the signal-to-noise ratio. If only works if the
participants follow the conventions.

Sometimes cross-posts make sense because it is not clear what area the
question would fall under. 2 groups is reasonable. 3 is about the limit.
4 is egregious.

I am not making any of this up. This is just standard netiquette.
http://www.google.com/search?hl=en&n...+cross+posting
-D
"Bob Rock" <no***************************@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

Maybe not exactly what you want, but you can get close like this:

public class Foo
{
ArrayList _classNames = new ArrayList();
[XmlArray("ClassNames"), XmlArrayItem("ClassName")]
public string[] ClassNames
{
get { return (string[])_classNames.ToArray(typeof(string)); }
set {_classNames = new ArrayList(value);}
}
}

Construct and serialize a Foo like this:

string[] names = new string[]{"f", "g", "h"};
Foo f = new Foo();
f.ClassNames = names;
Console.WriteLine(SerializeThingToXmlString(f));
Where the helper method is:

static string SerializeThingToXmlString(object thing)
{
StringWriter stringWriter = new StringWriter();
XmlSerializer serializer = new XmlSerializer(thing.GetType());
serializer.Serialize(stringWriter, thing);
return stringWriter.ToString();
}

--
Mickey Williams
Author, "Microsoft Visual C# .NET Core Reference", MS Press
www.servergeek.com/blogs/mickey

[Bob Rock]

> > Ahhh, so that is the way you can use the XmlArrayAttribute and

XmlArrayItemAttribute on something that is not a field!!!
Is it possible to use it on methods returning arrays???
Methods can return instances of Foo. Those instances of Foo will behave

as indicated by the attributes on Foo.
If your method returns an array, then the attributes that apply are those on the base type.
So if it is an array of Foo that is being returned, then the attributes on
the Foo definition will apply to the elements of the array.
The point here is not controlling the serialization of the elements of an
array, but of the array itself, in other words of the xml root element.
I believe it is not possible to effectively attribute arrays if they are not serialized as members of classes. In other words, if it is a local variable and you want to serialize it, I believe the attributes do not apply.
That is not true ... controlling serialization of a class field that is an
array is indeed very simple (XmlArrayAttribute and XmlArrayItemAttribute is
all that is needed).
Also
if the array is a member variable and you do not serialize the entire class, then I believe the attributes do not apply.

I've also seen that there is a way of setting the root node element to
whatever one wants using the XmlSerializer(Type, XmlRootAttribute)
constructor. Unfortunately when deserializing I need to change the root node

element to <ArrayOfClassname> as the XmlSerializer expects to avoid the
exception.

Yes this should work, but I don't understand what the problem is on
de-serializing. If you are using the same kind of XmlSerializer
(constructed with the XmlRootAttribute), then the string or stream with

the modified root node should de-serialize just fine. eg
Again, this is not true. Using the XmlSerializer constructor with the
XmlRootAttribute parameter lets you control only serialization ... it does
not make the XmlSerializer instance *understand* an xml with the root node
set to the XmlRootAttribute parameter you are passing in when using that
XmlSerializer instance to deserialize an xml into the array. It *still*
expects the xml that it would generate normally (the one with
<ArrayOfClassname>).

Sorry for the cross-posting, but it is done only in the hope that more people may read (and hopefully answer) my post.

. Yes, more people see it. But not more
people who care, or who will have anything to contribute.
This is just your personal opinion.
I posted not on *any* NG, but on NGs that I felt are visited by people that
could have the answer I was looking for .... xml or web services newsgroups
(and I believe serialization is something that should be well known by
people dealing with WS).
You could also
ask xml serialization questions to people you meet in the subway on the way to work, or at church, or in the stands at the ballgame, but I doubt you'll have much success there either.

Imagine if everyone followed your policy. Every question on every topic
would get asked on every group. Would that work? The different groups are set up to raise the signal-to-noise ratio. If only works if the
participants follow the conventions.

Sometimes cross-posts make sense because it is not clear what area the
question would fall under. 2 groups is reasonable. 3 is about the limit.
4 is egregious.

I am not making any of this up. This is just standard netiquette.
http://www.google.com/search?hl=en&n...+cross+posting
-D

Bob Rock

[Bob Rock]

> > Ahhh, so that is the way you can use the XmlArrayAttribute and

XmlArrayItemAttribute on something that is not a field!!!
Is it possible to use it on methods returning arrays???
Methods can return instances of Foo. Those instances of Foo will behave

as indicated by the attributes on Foo.
If your method returns an array, then the attributes that apply are those on the base type.
So if it is an array of Foo that is being returned, then the attributes on
the Foo definition will apply to the elements of the array.
The point here is not controlling the serialization of the elements of an
array, but of the array itself, in other words of the xml root element.
I believe it is not possible to effectively attribute arrays if they are not serialized as members of classes. In other words, if it is a local variable and you want to serialize it, I believe the attributes do not apply.
That is not true ... controlling serialization of a class field that is an
array is indeed very simple (XmlArrayAttribute and XmlArrayItemAttribute is
all that is needed).
Also
if the array is a member variable and you do not serialize the entire class, then I believe the attributes do not apply.

I've also seen that there is a way of setting the root node element to
whatever one wants using the XmlSerializer(Type, XmlRootAttribute)
constructor. Unfortunately when deserializing I need to change the root node

element to <ArrayOfClassname> as the XmlSerializer expects to avoid the
exception.

Yes this should work, but I don't understand what the problem is on
de-serializing. If you are using the same kind of XmlSerializer
(constructed with the XmlRootAttribute), then the string or stream with

the modified root node should de-serialize just fine. eg
Again, this is not true. Using the XmlSerializer constructor with the
XmlRootAttribute parameter lets you control only serialization ... it does
not make the XmlSerializer instance *understand* an xml with the root node
set to the XmlRootAttribute parameter you are passing in when using that
XmlSerializer instance to deserialize an xml into the array. It *still*
expects the xml that it would generate normally (the one with
<ArrayOfClassname>).

Sorry for the cross-posting, but it is done only in the hope that more people may read (and hopefully answer) my post.

. Yes, more people see it. But not more
people who care, or who will have anything to contribute.
This is just your personal opinion.
I posted not on *any* NG, but on NGs that I felt are visited by people that
could have the answer I was looking for .... xml or web services newsgroups
(and I believe serialization is something that should be well known by
people dealing with WS).
You could also
ask xml serialization questions to people you meet in the subway on the way to work, or at church, or in the stands at the ballgame, but I doubt you'll have much success there either.

Imagine if everyone followed your policy. Every question on every topic
would get asked on every group. Would that work? The different groups are set up to raise the signal-to-noise ratio. If only works if the
participants follow the conventions.

Sometimes cross-posts make sense because it is not clear what area the
question would fall under. 2 groups is reasonable. 3 is about the limit.
4 is egregious.

I am not making any of this up. This is just standard netiquette.
http://www.google.com/search?hl=en&n...+cross+posting
-D

Bob Rock

[Ming Chen [.NET MVP]]

Hi, Bob.
One solution I can think right out-of-the box is:

public class Classnames {
[XmlElement("Classname")]
public Classname[] Members;
......
}

By applying XmlElementAttribute to an array, You can eliminate the
ArrayOfClassname/Members element from the serialized result. And by wrapping
the array in a class named Classnames, you can make sure the result Xml has
a Classnames root element. The net effect is that you get an Xml document
that has a Classnames root and a list of Classname.

On the other hand, .NET does allow XmlXXXAttributes to be applied on
function return value. But there isn't any easy way to leverage it. E.g:
WebService engine utilizes this through XmlMapping, which is marked "not
intended to be used directly from your code" in MSDN. I think that you can
still use XmlMapping classes, though.

Hope this helps.
Ming Chen [.NET MVP]

"Bob Rock" <no***************************@hotmail.com> wrote in message
news:O3*************@tk2msftngp13.phx.gbl...

Hello,

when serializing an array of elements of a class Classname using
XmlSerializer.Serialize() I get an XML like the following:

<?xml version="1.0">
<ArrayOfClassname>
......
......
</ArrayOfClassname>

I'd like to be able to set the XML root node to something different from
<ArrayOfClassname> .... for example something like <Classnames>.
As an alternative when deserilizing an XML such as the following:

<?xml version="1.0">
<Classnames>
......
......
</Classnames>

I'd like to be able to "load" it into an array of objects of class Classname (at the moment when making such an attempt I get an obvious exception
stating "<Classnames> was not expected").
Bob Rock

[Ming Chen [.NET MVP]]

Hi, Bob.
One solution I can think right out-of-the box is:

public class Classnames {
[XmlElement("Classname")]
public Classname[] Members;
......
}

By applying XmlElementAttribute to an array, You can eliminate the
ArrayOfClassname/Members element from the serialized result. And by wrapping
the array in a class named Classnames, you can make sure the result Xml has
a Classnames root element. The net effect is that you get an Xml document
that has a Classnames root and a list of Classname.

On the other hand, .NET does allow XmlXXXAttributes to be applied on
function return value. But there isn't any easy way to leverage it. E.g:
WebService engine utilizes this through XmlMapping, which is marked "not
intended to be used directly from your code" in MSDN. I think that you can
still use XmlMapping classes, though.

Hope this helps.
Ming Chen [.NET MVP]

"Bob Rock" <no***************************@hotmail.com> wrote in message
news:O3*************@tk2msftngp13.phx.gbl...

Hello,

when serializing an array of elements of a class Classname using
XmlSerializer.Serialize() I get an XML like the following:

<?xml version="1.0">
<ArrayOfClassname>
......
......
</ArrayOfClassname>

I'd like to be able to set the XML root node to something different from
<ArrayOfClassname> .... for example something like <Classnames>.
As an alternative when deserilizing an XML such as the following:

<?xml version="1.0">
<Classnames>
......
......
</Classnames>

I'd like to be able to "load" it into an array of objects of class Classname (at the moment when making such an attempt I get an obvious exception
stating "<Classnames> was not expected").
Bob Rock

[Daniel Cazzulino [MVP XML]]

You can use:

[WebMethod]
[return: XmlArray("Customers")]
public Customer[] GetCustomers()

HTH

--
Daniel Cazzulino [MVP XML]
Clarius Consulting SA
http://weblogs.asp.net/cazzu
http://aspnet2.com

"Bob Rock" <no***************************@hotmail.com> wrote in message
news:eE**************@TK2MSFTNGP09.phx.gbl...

Ahhh, so that is the way you can use the XmlArrayAttribute and
XmlArrayItemAttribute on something that is not a field!!!
Is it possible to use it on methods returning arrays???
Methods can return instances of Foo. Those instances of Foo will behave

as

indicated by the attributes on Foo.
If your method returns an array, then the attributes that apply are those on

the base type.
So if it is an array of Foo that is being returned, then the attributes

on the Foo definition will apply to the elements of the array.

The point here is not controlling the serialization of the elements of an
array, but of the array itself, in other words of the xml root element.

I believe it is not possible to effectively attribute arrays if they are

not

serialized as members of classes. In other words, if it is a local

variable

and you want to serialize it, I believe the attributes do not apply.

That is not true ... controlling serialization of a class field that is an
array is indeed very simple (XmlArrayAttribute and XmlArrayItemAttribute

is all that is needed).

Also
if the array is a member variable and you do not serialize the entire class,

then I believe the attributes do not apply.

I've also seen that there is a way of setting the root node element to
whatever one wants using the XmlSerializer(Type, XmlRootAttribute)
constructor. Unfortunately when deserializing I need to change the root

node

element to <ArrayOfClassname> as the XmlSerializer expects to avoid

the exception.

Yes this should work, but I don't understand what the problem is on
de-serializing. If you are using the same kind of XmlSerializer
(constructed with the XmlRootAttribute), then the string or stream with

the

modified root node should de-serialize just fine. eg

Again, this is not true. Using the XmlSerializer constructor with the
XmlRootAttribute parameter lets you control only serialization ... it does
not make the XmlSerializer instance *understand* an xml with the root node
set to the XmlRootAttribute parameter you are passing in when using that
XmlSerializer instance to deserialize an xml into the array. It *still*
expects the xml that it would generate normally (the one with
<ArrayOfClassname>).

Sorry for the cross-posting, but it is done only in the hope that more

people may read (and hopefully answer) my post.

. Yes, more people see it. But not more
people who care, or who will have anything to contribute.

This is just your personal opinion.
I posted not on *any* NG, but on NGs that I felt are visited by people

that could have the answer I was looking for .... xml or web services newsgroups (and I believe serialization is something that should be well known by
people dealing with WS).

You could also
ask xml serialization questions to people you meet in the subway on the

way

to work, or at church, or in the stands at the ballgame, but I doubt

you'll

have much success there either.

Imagine if everyone followed your policy. Every question on every topic
would get asked on every group. Would that work? The different groups

are

set up to raise the signal-to-noise ratio. If only works if the
participants follow the conventions.

Sometimes cross-posts make sense because it is not clear what area the
question would fall under. 2 groups is reasonable. 3 is about the

limit. 4 is egregious.

I am not making any of this up. This is just standard netiquette.
http://www.google.com/search?hl=en&n...+cross+posting
-D

Bob Rock

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.708 / Virus Database: 464 - Release Date: 18/06/2004

[Daniel Cazzulino [MVP XML]]

You can use:

[WebMethod]
[return: XmlArray("Customers")]
public Customer[] GetCustomers()

HTH

--
Daniel Cazzulino [MVP XML]
Clarius Consulting SA
http://weblogs.asp.net/cazzu
http://aspnet2.com

"Bob Rock" <no***************************@hotmail.com> wrote in message
news:eE**************@TK2MSFTNGP09.phx.gbl...

Ahhh, so that is the way you can use the XmlArrayAttribute and
XmlArrayItemAttribute on something that is not a field!!!
Is it possible to use it on methods returning arrays???
Methods can return instances of Foo. Those instances of Foo will behave

as

indicated by the attributes on Foo.
If your method returns an array, then the attributes that apply are those on

the base type.
So if it is an array of Foo that is being returned, then the attributes

on the Foo definition will apply to the elements of the array.

The point here is not controlling the serialization of the elements of an
array, but of the array itself, in other words of the xml root element.

I believe it is not possible to effectively attribute arrays if they are

not

serialized as members of classes. In other words, if it is a local

variable

and you want to serialize it, I believe the attributes do not apply.

That is not true ... controlling serialization of a class field that is an
array is indeed very simple (XmlArrayAttribute and XmlArrayItemAttribute

is all that is needed).

Also
if the array is a member variable and you do not serialize the entire class,

then I believe the attributes do not apply.

I've also seen that there is a way of setting the root node element to
whatever one wants using the XmlSerializer(Type, XmlRootAttribute)
constructor. Unfortunately when deserializing I need to change the root

node

element to <ArrayOfClassname> as the XmlSerializer expects to avoid

the exception.

Yes this should work, but I don't understand what the problem is on
de-serializing. If you are using the same kind of XmlSerializer
(constructed with the XmlRootAttribute), then the string or stream with

the

modified root node should de-serialize just fine. eg

Again, this is not true. Using the XmlSerializer constructor with the
XmlRootAttribute parameter lets you control only serialization ... it does
not make the XmlSerializer instance *understand* an xml with the root node
set to the XmlRootAttribute parameter you are passing in when using that
XmlSerializer instance to deserialize an xml into the array. It *still*
expects the xml that it would generate normally (the one with
<ArrayOfClassname>).

Sorry for the cross-posting, but it is done only in the hope that more

people may read (and hopefully answer) my post.

. Yes, more people see it. But not more
people who care, or who will have anything to contribute.

This is just your personal opinion.
I posted not on *any* NG, but on NGs that I felt are visited by people

that could have the answer I was looking for .... xml or web services newsgroups (and I believe serialization is something that should be well known by
people dealing with WS).

You could also
ask xml serialization questions to people you meet in the subway on the

way

to work, or at church, or in the stands at the ballgame, but I doubt

you'll

have much success there either.

Imagine if everyone followed your policy. Every question on every topic
would get asked on every group. Would that work? The different groups

are

set up to raise the signal-to-noise ratio. If only works if the
participants follow the conventions.

Sometimes cross-posts make sense because it is not clear what area the
question would fall under. 2 groups is reasonable. 3 is about the

limit. 4 is egregious.

I am not making any of this up. This is just standard netiquette.
http://www.google.com/search?hl=en&n...+cross+posting
-D

Bob Rock

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.708 / Virus Database: 464 - Release Date: 18/06/2004