Help with ISerializable help file paragraph.

[Rene]

OK, I give up, the msdn help for custom serialization:

http://msdn2.microsoft.com/en-us/library/ty01x675(VS.90).aspx

Hs the following paragraph on it:

-----
In addition, you should not use default serialization on a class that is
marked with the Serializable attribute and has declarative or imperative
security at the class level or on its constructors. Instead, these classes
should always implement the ISerializable interface.
-----

Why?? Could someone tell me PLEASE what a heck does this mean? Why would
having imperative security at the class level or on its constructors have
anything to do with nothing?? What kind of security is this thing talking
about?

Thank you.

 

[Family Tree Mike]

OK, I give up, the msdn help for custom serialization:

http://msdn2.microsoft.com/en-us/library/ty01x675(VS.90).aspx

Hs the following paragraph on it:

-----
In addition, you should not use default serialization on a class that is
marked with the Serializable attribute and has declarative or imperative
security at the class level or on its constructors. Instead, these classes
should always implement the ISerializable interface.
-----

Why?? Could someone tell me PLEASE what a heck does this mean? Why would
having imperative security at the class level or on its constructors have
anything to do with nothing?? What kind of security is this thing talking
about?

Thank you.

My guess is that this is an obtuse way of describing that XML serialization
needs a public default constructor.

 

[Marc Gravell]

My guess is that this is an obtuse way of describing that XML serialization

needs a public default constructor.

True: xml serialization *does* need a default ctor, but ISerializable
is for binary serialization (IXmlSerializable is for xml).

I don't claim to fully understand the paragraph myself - I'm just
trying to avoid a red herring...

Marc

 

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

Actually, ISerializable is not for binary serialization specifically,
but the serialization engine in System.Runtime.Serialization. This engine
will use reflection to get the internal members of a type, as opposed to Xml
serialization, which only works with the public members. Also, the
serialization engine in System.Runtime.Serialization supports multiple
formatters (soap, binary), whereas there is only one format for XML
Serialization.

 

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

Rene,

What this means is that if you have declarative security attributes on
your instance, or if you are making explicit calls to the Demand method on
permission objects, you should implement ISerializable.

The reason for this is that constructors are not called when serialized
instances are created, except when using custom serialization (ISerializable
and the constructor with the specific declaration). Because of this, if you
have any security on the class level or constructor level, it is not applied
when deserializing instances. In order to preserve that, you have to
declare the custom constructor and apply the declarative security there, or
make the explicit call in the constructor.

 

[Rene]

Thanks Nicolas!!

It all makes sense now, I think I was this >< close from figuring it out
after 2 hours of searching online obsessing for the answer. Of course, I am
sure all this formatter stuff is probably obsolete with the new .Net 3.5
framework but hey, what am I supposed to do!!

Now all I have left to do is try to figure out why the serialization special
constructor is not called "virtualized" the same way the "GetObjectData"
method is called. According to some document I read online, this used to be
the way it was done but not anymore. My guess is that is something to do
with security?

Again, thanks for your help... by the way, I have not been able to find
bacon ice cream where I live, you must live on some obscure part of the
country

Thanks.

Rene,

What this means is that if you have declarative security attributes on
your instance, or if you are making explicit calls to the Demand method on
permission objects, you should implement ISerializable.

The reason for this is that constructors are not called when serialized
instances are created, except when using custom serialization
(ISerializable and the constructor with the specific declaration).
Because of this, if you have any security on the class level or
constructor level, it is not applied when deserializing instances. In
order to preserve that, you have to declare the custom constructor and
apply the declarative security there, or make the explicit call in the
constructor.


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

OK, I give up, the msdn help for custom serialization:

http://msdn2.microsoft.com/en-us/library/ty01x675(VS.90).aspx

Hs the following paragraph on it:

-----
In addition, you should not use default serialization on a class that is
marked with the Serializable attribute and has declarative or imperative
security at the class level or on its constructors. Instead, these
classes should always implement the ISerializable interface.
-----

Why?? Could someone tell me PLEASE what a heck does this mean? Why would
having imperative security at the class level or on its constructors have
anything to do with nothing?? What kind of security is this thing talking
about?

Thank you.