XML Serialization

[Guest]

Hi,

We have an app that uses XML serialization throughout. As everyone probably
knows, using XML serialization is not always a good idea in a big project
(http://www.codeproject.com/dotnet/noserialise.asp).

I found this article:
http://weblogs.asp.net/cazzu/archive/2003/10/21/32822.aspx

and realized that I could access the code that the XMLSerializer had
generated and compile it in my application. This works just
great...however...I've noticed that the source code generated uses methods
like "WriteElementStringRaw" which are not to be used directly by developers.
I assume this means that Microsoft reserves the right to change or remove
such methods in the future. What do other think about using XMLSerializer
generated source directly?

Thanks,
Nate

 

[Nicholas Paldino [.NET/C# MVP]]

Nate,

With the introduction of .NET 3.0, I think that the use of the
XmlSerializer can be minimized, considering the introduction of the
DataContractSerializer. This will allow for the serialization of an
instance of a class which adheres to a contract, as opposed to a concrete
type. What this translates to is that you can serialize your instances into
XML without all the restrictions of the XmlSerializer (and get XML that is
relatively clean as compared to the SoapSerializer).

You might want to take a look at that.

 

[Kevin Spencer]

I wouldn't put much stock in that first article. It mixes up XML
Serialization with other types of Serialization as if there were no
difference between them. It alternates between discussing XML Serialization
and other forms of serialization without making much (if any) discrimination
between them. It also contains a number of weak arguments, and a few silly
ones, and the author admittedly doesn't understand "how serialization
works."

I would suggest that you do what the author did not, and try to learn more
about XML serialization, what it is used for, why it is used, and why in
some cases it is the best possible solution. You might be surprised for
example, to find out that the latest version of Microsoft Word uses a
serialized XML file format. You might want to ask yourself why Microsoft
thinks that's the best thing to do.

Only after you've studied and understood XML serialization can you examine
the requirements of your particular application and how, if, and when XML
serialization might or might not be useful. Then you can make an informed
and wise decision about the best way to go.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[Peter Duniho]

Hi,

We have an app that uses XML serialization throughout. As everyone
probably
knows, using XML serialization is not always a good idea in a big project
(http://www.codeproject.com/dotnet/noserialise.asp).

What a goofy article.

It was written almost three years ago, and claims that .NET won't be
around in another couple of years from now (it claimed .NET would be gone
in 5 years). I'd say if anything, .NET is likely to be the major
programming architecture in Windows for as much as the next decade,
possibly even longer (look how long the native Windows API has been with
us in one form or another, and it's _still_ a perfectly viable API).

It also makes some pretty funny assertions about security (as if you can't
securely serialize, and as if other serialization mechanisms implicitly
ensure security), implementation (that serialization is a "black box" is
no more of a problem than anything else .NET does for you), and
"weirdness" (the author has a problem understanding why the children of a
data object may not be instantiated before the parent...why this qualifies
as "weird" I have no idea).

It also makes the assumption that the automatic "[Serializable]" mechanism
in .NET is the only viable way to serialize, which as I learned recently
when I looked into serialization is simply false.

I could go on, but frankly...I hope no one is really taking the article
seriously. I'd hardly characterize what was written in that article as
something "everyone probably knows", nor does the article seem to be
targeted only at "a big project".

I found this article:
http://weblogs.asp.net/cazzu/archive/2003/10/21/32822.aspx

and realized that I could access the code that the XMLSerializer had
generated and compile it in my application. [...]
What do other think about using XMLSerializer
generated source directly?

I think it's a bad idea. And for essentially the reason you already point
out: it uses private methods that are not guaranteed to exist in the
future. Talk about not being "future proof"! The auto-generated code
used by the "[Serializable]" mechanism is an implementation detail, not
part of the API. You should be using the API, or something else
entirely. Using an API while making deep assumptions about the
implementation of the API completely negates the whole point of using the
API in the first place.

Pete

 

[Guest]

Hi Nicholas,

Thanks, I'll take a look at Framework 3.0. Unfortunately we aren't moving
to 3.0 in this software release, but we will move to it in the future.

Right now, the biggest problem we have with XMLSerializer is that our
initial implementation exposed a bunch of members that should not be visible
to the outside world. (We were racing to get things implemented and as a
result, encapsulation in our app sucks.) It would be great if the
DataContractSerializer could serialize private members and/or properties.
Many implementation details of our current classes are exposed to the outside
world just because of XMLSerialization and our unbending requirement to be
backwards compatible with all of our files.

Thanks,
Nate

Nate,

With the introduction of .NET 3.0, I think that the use of the
XmlSerializer can be minimized, considering the introduction of the
DataContractSerializer. This will allow for the serialization of an
instance of a class which adheres to a contract, as opposed to a concrete
type. What this translates to is that you can serialize your instances into
XML without all the restrictions of the XmlSerializer (and get XML that is
relatively clean as compared to the SoapSerializer).

You might want to take a look at that.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi,

We have an app that uses XML serialization throughout. As everyone
probably
knows, using XML serialization is not always a good idea in a big project
(http://www.codeproject.com/dotnet/noserialise.asp).

I found this article:
http://weblogs.asp.net/cazzu/archive/2003/10/21/32822.aspx

and realized that I could access the code that the XMLSerializer had
generated and compile it in my application. This works just
great...however...I've noticed that the source code generated uses methods
like "WriteElementStringRaw" which are not to be used directly by
developers.
I assume this means that Microsoft reserves the right to change or remove
such methods in the future. What do other think about using XMLSerializer
generated source directly?

Thanks,
Nate

 

[Nicholas Paldino [.NET/C# MVP]]

Nathan,

That's exactly what DataContractSerializer does. It offers the simple
representation that the XmlSerializer offers with the power that traditional
serialization offers in that you can serialize private members.

You might also be able to fast-track adoption of .NET 3.0 as well if you
are currently using .NET 2.0. .NET 3.0 was not changes to anything, but
rather, additions to .NET 2.0.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi Nicholas,

Thanks, I'll take a look at Framework 3.0. Unfortunately we aren't moving
to 3.0 in this software release, but we will move to it in the future.

Right now, the biggest problem we have with XMLSerializer is that our
initial implementation exposed a bunch of members that should not be
visible
to the outside world. (We were racing to get things implemented and as a
result, encapsulation in our app sucks.) It would be great if the
DataContractSerializer could serialize private members and/or properties.
Many implementation details of our current classes are exposed to the
outside
world just because of XMLSerialization and our unbending requirement to be
backwards compatible with all of our files.

Thanks,
Nate

Nate,

With the introduction of .NET 3.0, I think that the use of the
XmlSerializer can be minimized, considering the introduction of the
DataContractSerializer. This will allow for the serialization of an
instance of a class which adheres to a contract, as opposed to a concrete
type. What this translates to is that you can serialize your instances
into
XML without all the restrictions of the XmlSerializer (and get XML that
is
relatively clean as compared to the SoapSerializer).

You might want to take a look at that.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


message

Hi,

We have an app that uses XML serialization throughout. As everyone
probably
knows, using XML serialization is not always a good idea in a big
project
(http://www.codeproject.com/dotnet/noserialise.asp).

I found this article:
http://weblogs.asp.net/cazzu/archive/2003/10/21/32822.aspx

and realized that I could access the code that the XMLSerializer had
generated and compile it in my application. This works just
great...however...I've noticed that the source code generated uses
methods
like "WriteElementStringRaw" which are not to be used directly by
developers.
I assume this means that Microsoft reserves the right to change or
remove
such methods in the future. What do other think about using
XMLSerializer
generated source directly?

Thanks,
Nate