469,362 Members | 2,450 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,362 developers. It's quick & easy.

C# Serialization and Events problem

I have a class (settings, etc.) which is derived from CollectionBase and
contains a number of fields and a few events. When I create an instance of
this class in my app, and serialize it, it works. If I add an event handler
in my app (for one of the events in my settings class), I get an exception
that my app class is not marked as Serializable. If I mark the app class as
Serializible, I get an exception that Type System.Windows.Forms.Form in
Assembly System.Windows.Form is not marked as Serializable. I am not
interested is serializing any data relating to the event, but it does not
seem possible to mark events/delegates as NonSerialized. Are events
serialized? How do I avoid this problem?
Jul 21 '05 #1
3 16008
Hello

Prefix the NonSerializedAttribute with "field:", this will make the C#
compiler mark the underlying delegate field and not the event itself as
NonSerialized.

[field:NonSerialized] public event MyEventHandler MyEvent;

Another workaround is using custom events (although I think the first
solution is simpler)

[NonSerialized]
private MyEventHandler _myEvent;
public event MyEventHandler MyEvent
{
add { _myEvent += value; } // Not Thread-safe
remove { _myEvent -= value; } // Not Thread-safe
}

Or use the thread safe version if your event can be accessed from multiple
threads

[NonSerialized]
private MyEventHandler _myEvent;
public event MyEventHandler MyEvent
{
add { lock(this) {_myEvent += value; } }
remove { lock(this) {_myEvent -= value; } }
}

Best regards,
Sherif
"mikeb" <mi***@discussions.microsoft.com> wrote in message
news:A7**********************************@microsof t.com...
I have a class (settings, etc.) which is derived from CollectionBase and
contains a number of fields and a few events. When I create an instance of
this class in my app, and serialize it, it works. If I add an event
handler
in my app (for one of the events in my settings class), I get an exception
that my app class is not marked as Serializable. If I mark the app class
as
Serializible, I get an exception that Type System.Windows.Forms.Form in
Assembly System.Windows.Form is not marked as Serializable. I am not
interested is serializing any data relating to the event, but it does not
seem possible to mark events/delegates as NonSerialized. Are events
serialized? How do I avoid this problem?

Jul 21 '05 #2
<"Sherif El-Metainy" <elmeteny REMOVETHIS at thewayout NOSPAM dot
net>> wrote:
Prefix the NonSerializedAttribute with "field:", this will make the C#
compiler mark the underlying delegate field and not the event itself as
NonSerialized.

[field:NonSerialized] public event MyEventHandler MyEvent;

Another workaround is using custom events (although I think the first
solution is simpler)

[NonSerialized]
private MyEventHandler _myEvent;
public event MyEventHandler MyEvent
{
add { _myEvent += value; } // Not Thread-safe
remove { _myEvent -= value; } // Not Thread-safe
}

Or use the thread safe version if your event can be accessed from multiple
threads

[NonSerialized]
private MyEventHandler _myEvent;
public event MyEventHandler MyEvent
{
add { lock(this) {_myEvent += value; } }
remove { lock(this) {_myEvent -= value; } }
}


One suggestion for the thread-safe version - rather than locking on
"this" (which is almost always a bad idea) lock on a privately owned
object.

See http://www.pobox.com/~skeet/csharp/t...ckchoice.shtml

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #3
Thanks for the help. I used the field prefix for now and everything works fine.

Mike B

"Sherif El-Metainy" wrote:
Hello

Prefix the NonSerializedAttribute with "field:", this will make the C#
compiler mark the underlying delegate field and not the event itself as
NonSerialized.

[field:NonSerialized] public event MyEventHandler MyEvent;

Another workaround is using custom events (although I think the first
solution is simpler)

[NonSerialized]
private MyEventHandler _myEvent;
public event MyEventHandler MyEvent
{
add { _myEvent += value; } // Not Thread-safe
remove { _myEvent -= value; } // Not Thread-safe
}

Or use the thread safe version if your event can be accessed from multiple
threads

[NonSerialized]
private MyEventHandler _myEvent;
public event MyEventHandler MyEvent
{
add { lock(this) {_myEvent += value; } }
remove { lock(this) {_myEvent -= value; } }
}

Best regards,
Sherif
"mikeb" <mi***@discussions.microsoft.com> wrote in message
news:A7**********************************@microsof t.com...
I have a class (settings, etc.) which is derived from CollectionBase and
contains a number of fields and a few events. When I create an instance of
this class in my app, and serialize it, it works. If I add an event
handler
in my app (for one of the events in my settings class), I get an exception
that my app class is not marked as Serializable. If I mark the app class
as
Serializible, I get an exception that Type System.Windows.Forms.Form in
Assembly System.Windows.Form is not marked as Serializable. I am not
interested is serializing any data relating to the event, but it does not
seem possible to mark events/delegates as NonSerialized. Are events
serialized? How do I avoid this problem?


Jul 21 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by VK | last post: by
2 posts views Thread by Jiho Han | last post: by
1 post views Thread by andrewcw | last post: by
4 posts views Thread by Tamir Khason | last post: by
reply views Thread by Sudhakar S P | last post: by
3 posts views Thread by mikeb | last post: by
reply views Thread by Miguel RS | last post: by
4 posts views Thread by Jeff User | last post: by
5 posts views Thread by screaminmartin | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.