nonserialization of events  
Author Message
PhilipDaniels





PostPosted: Visual C# General, nonserialization of events Top

I know how to do it ie [field:NonSerialize], but I do not understand why I need specify the field: attribute target. Incidentally it works fine, but finding it was not easy - I found it in the ECMA Language Specification, not a particularly easy read, later I found it in an MSDN article. But they do not explain the "why", just the "what".

And, how can I access, via Reflection, attributes with a specific target. When I get the custom attributes for an event with the [field:NonSerialzed] attribute via the EventInfo.GetCustomAttributes method it is not reported. Nor can I figure how to access an event's underlying "field"; unlike a methods return value which is available from MethodInfo and or MethodBase (I forget which). This is another case where one might need to target an attribute at a "characterestic" of the member in question - ie the return type is a characteristic of a method, I suspect there is more than one "field" characteristic in and event.

Thanks PhilD






Visual C#14  
 
 
Mattias Sjogren





PostPosted: Visual C# General, nonserialization of events Top

I know how to do it ie [field:NonSerialize], but I do not understand why I need specify the field: attribute target. Incidentally it works fine, but finding it was not easy - I found it in the ECMA Language Specification, not a particularly easy read, later I found it in an MSDN article. But they do not explain the "why", just the "what".

Because the NonSerialized attribute can only be applied to fields (that is, after all, what gets serialized).


Nor can I figure how to access an event's underlying "field"; unlike a methods return value which is available from MethodInfo and or MethodBase (I forget which).

There's no easy way to get that. The whole point of events is to hide the backing delegate, and there might not even be a separate delegate field for the event. The best you can do here is guess the name of the delegate field from the event's name (different compilers use different naming schemes for events and delegates).



 
 
PhilipDaniels





PostPosted: Visual C# General, nonserialization of events Top

Mattias, are you saying that "only fields" within a class get Serialised or that only the field characteristic of an event gets Serialised, I assume its the latter.

The mysterious field that gets serialised obviously contains references to the event handlers, as it was the existence of a handler within a Windows.Forms.Form derivative that led me into trouble. Prior to adding that handler the event was being serialised, however I'm not losing anything by not deserialising the event.

Thanks for the feedback - for the record I'd prefer to see less hiding of event processing - at the bottom of my heart I'm not convinced it should even present as a language element.

Rgds phild



 
 
Mattias Sjogren





PostPosted: Visual C# General, nonserialization of events Top

I'm not sure exactly what you mean by "field characteristic of an event". An event is really just two or more accessor methods and a backing store (usually a separate field).

If you think the auto generated field is "mysterious" you can use the more explicit event syntax where you manually implement the accessors and delegate storage.



 
 
PhilipDaniels





PostPosted: Visual C# General, nonserialization of events Top

Another problem I have with C# is that it uses up too many useful words, my use of the word "characteristic" was to indicate something like the "attributes" or "properties" of the entity in question. Pity CompSci grads cant be more imaginative when labelling things - like physicists do with their quarks, bosons and black holes that have charm, spin and event horizons.

However I've discovered that whilst the field itself is not available from the EventInfo class - its "mysterious" presence is reported as a field, with the same name as the event, via the declaring class' type GetFields method. I did not notice it the other day, but I've been "playing" around with the BindingFlags property and perhaps the value my assembly analyser was using last weekend precluded the reporting of such fields. And the field member DOES report the NonSerialised attribute - so in order to get a the complete story on an event one has to synthesise the EventInfo and FieldInfo objects into a composite "gizmo".

I haven't looked at what Type.GetMembers() returns, ie does it report the event as an event and a field.

Bottom line is that I now have a way of determining that an event is marked as NonSerializable - which means it'll get documented - I don't like documenting within the code, so I'm developing an external documentation facility, if I ever finish it I'll put it in te public domain.

Cheers PhilD