Do not serialize delegates and events blindly

My blog has moved. You can view this post at the following address: http://www.osherove.com/blog/2004/12/29/do-not-serialize-delegates-and-events-blindly.html
Published Wednesday, December 29, 2004 4:50 PM by RoyOsherove
Filed under:

Comments

Wednesday, December 29, 2004 6:14 AM by TrackBack

# Serious .NET Architecture Discussions

Wednesday, December 29, 2004 10:28 AM by David Hayden

# re: Do not serialize delegates and events blindly

The book, Expert C# (or VB.NET) Business Objects, mentions that little tidbit as well. I did a chapter by chapter summary of the book, which is a fun read. It has some good information on reflection, attributes, remoting, serialization, etc.

http://davidhayden.com/blog/dave/archive/2004/09/11/471.aspx
Wednesday, December 29, 2004 12:28 PM by Mattias Sjögren

# re: Do not serialize delegates and events blindly

No, field (lowercase f) is an attribute target. http://msdn.microsoft.com/library/en-us/csref/html/vclrfAttributeTargets.asp
Wednesday, December 29, 2004 1:56 PM by Roy Osherove

# re: Do not serialize delegates and events blindly

Mattias: Well "Field" it actually is. Compiles and all that too. Funnily enough, Resharper flags it as bad code... but it still compiles
Wednesday, December 29, 2004 3:25 PM by Sahil Malik

# RE: Do not serialize delegates and events blindly

Roy,

Curiously enough, this seems to work in .NET 2.0 even without the NonSerialized attribute being placed on delegates. What's even curious-er, the subscriptions to the delegates even are deserialized properly. Are you saying we should stay away from that *feature* ?

- Sahil
Wednesday, December 29, 2004 3:43 PM by Roy Osherove

# re: Do not serialize delegates and events blindly

Sahil: yeah - you should stay away from serializing and deserializing your delegates, because the way serializtion works, it will take the object and all the fields it has and serialize them. It will *recursively* go throuh each object's fields and serialize thos as well. For evenets and delegates, this means that it will go through all the current subscribers of the event and serialize them as well. It *might* work, but what happens when you have a class that cannot be serialized that subscribes to your event? Your serialization will fail. Since you can't *force* your subscribers to be serializable (that's the whole idea with the publish subscribe model - you never know who listens to your events) you should always assume that they are not playing nice, thus - you should avoid from serializing them using the [nonserialized] attribute.
Wednesday, December 29, 2004 4:50 PM by Mattias Sjögren

# re: Do not serialize delegates and events blindly

With a capital F it compiles here too (with the v1.1 compiler), but the attribute flag isn't there (you can check with Ildasm or whatever) and I get the following warning:

warning CS0658: 'Field' is not a recognized attribute location. All attributes in this block will be ignored.

This should really be an error rather than a warning IMO.
Wednesday, December 29, 2004 6:09 PM by Sahil Malik

# re: Do not serialize delegates and events blindly

Roy make sense, but I've been trying hard to make Serialization using the BinaryFormatter fail using the [Serializable] attribute, but it always seems to work LOL. I understand the infinitely recursive pattern, though there is the situation where you serialize something on one machine, transport it to another, and deserialize where the subscribers aren't there .. then what happens !! It still didn't fail LOL.

Anyway, I understand the argument, though in practice I've been myself arguing with it in my head. Could it be said that "Because it's so automatic, be scared of anything that is so automatic since you don't really know what it'll do cuz it has a mind of it's own". .. I guess I'm stickin' to that theory.
Wednesday, July 12, 2006 10:38 AM by Sam

# re: Do not serialize delegates and events blindly

Nice solution. I wasted a lot of time on this. For Sahil: My business object was raising events that a form was subscribing to. WinForm cannot be serialized, or marked as such. Hope this will stop the argument in your head!