Hi josh,
We don't need to argue the point as to whether or not this is necessary or a
good idea. I'll just take you at your word that you want this, regardless.
:-)
After a good bit of research, both into Binary Serialization and into XML
Serialization, I can only offer guesses as to why the BinaryFormatter raises
this event, but the XmlSerializer does not. Binary Serialization is often
used with Remoting, and is used when performance and latency are more of an
issue than when using XML Serialization. After all, XML Serialization is
generally used locally, or via Web Services. With Web Services, latency is
expected. Again, I'm just guessing here. With Binary Serialization, it is
possible to serialize every member of a class, both data and process, but at
a cost. So, from the examples I've seen, the IDeserializationCallback was
used to allow the deserialized class to reconstruct members that were not
serialized, with the justification being that performance was gained in not
serializing these members.
Now, I suppose it is conceivable that one might want to do something like
this with XML Serialization. For whatever reasons, it just doesn't exist in
the System.Xml.Serialization NameSpace. What you can do is to implement your
own class(es) that do this, if you like. Otherwise, you may as well stick
with what you're presently working with.
Sorry I couldn't be more help.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.
"yoshijg" <jo*****@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
Hey Kev,
First ... I just want to say I appreciate your feed back on this. I
truly enjoy hearing other people's perspective on programming.
I am not trying to notify the object that they have "woken up", so I
agree with you on that. What I am trying to do is finish the creation
of the object by filling in the holes during the "OnDeserialization"
method, because that is the last method called before the object is
returned to the user. Kind of like the "Render" method in "asp.net" it
is the last point where you can alter the html before it is sent to the
client/browser.
You may still not see eye to eye with me on this, but there are
situations where I cant serialize everything to disk. For example, I
can't serialize a password field straight on to disk, but I can write
the "encrypted" value in place of it. Then during deserialization I
need to decrypt the value back to it's original form. Doing that type
of "clean up" in the "OnDeserialization" method would be an ideal
location ... right?
This is just an example I thought of now, so I am sure there are other
ways to solve it.
"Callbacks" / notifications occur throughout the framework. I just
find it weird and inconsistent that the "IDeserializationCallback"
would work for "BinaryFormatter" but not for "Xml" format.
So... If you dont see the need for callbacks on deserialization, then
can you answer why the "IDeserializationCallback" exists? and.. Why
does it work for "BinaryFormatter", but not for the "XmlSerializer" ?
I have some theories on this, but they are just theories after all.
Thanks kev.
peace,
josh