I notice when moving from VB.NET -> C# that the overloads are different
for

<XMLRoot(....) >
[XMLRoot(....) ]

<XMLElement(....) >
[XMLElement( ....) ]

but in notice the following seems to compile in C#
[XmlRoot(ElementName="message", Namespace="http://myurl")]

even though this is option is not shown Intellisense.

i imagine this related to C# not supporting optional parameters.

But is it ok to proceed as above?

Dickster

also tell me this:

Why to i have to capatalise the first letter in ElementName & Type when
the documentation says:
XmlElementAttribute(String elementName,System.Type type)

This doesnt compile
[XmlElementAttribute(elementName="dickster",type =
typeof(dickstersClass))]

But this does compile
[XmlElementAttribute(ElementName="dickster",Type =
typeof(dickstersClass))]

[quoted text, click to view]

There is a fundamental difference between [XmlElement( "Joe")] and
[XmlElement( ElementName = "Joe")].

The first case is creating the XmlElementAttribute by calling the constructor
that takes a single string argument. As you've mentioned, the name of that
parameter is elementName, but it doesn't really -- the fact is it's a constructor
that takes one string and that's all the runtime cares about. The sequence of
arguments matters, because it must match the formal parameters list of the
constructor.

The second case creates the XmlElementAttribute by calling the default
constructor which takes no arguments. After it constructs the XmlElement-
Attribute, it then goes through and sets properties on it. The property name
is ElementName, proper case and case sensitive.

[XmlElement( ElementName = "Joe", Type = typeof( Restauranteur))], and
[XmlElement( Type = typeof( Restauranteur), ElementName = "Joe")]

are the same except for the order in which the properties get assigned. Thus,
it's not a magical way of passing parameters to a constructor where the run-
time magically figures out what you meant to do, but a standard feature that
is applicable by necessity.

Think of the requirements for XmlElementAttribute, and runtime attributes in
general, if there needed to be overloaded constructors for every possible
combination of properties developers might want to set? Without them, it
would be terribly inconvenient to set some of the less-frequently used
properties like IsNullable and Form (GetCustomAttributes( ) at run-time,
anyone?)


Derek Harmon