views:

26

answers:

2

I'm attempting to re-organize my application's namespace hierarchy, so I'm using a System.Runtime.Serialization.SerializationBinder sub-class to attempt to handle the renaming. (Most of my renamed classes are correctly deserialized into their new namespaces without problems.)

The problem I have is that one of my serialized classes (which implements INotifyPropertyChanged) failed to mark the PropertyChanged event as [field:NonSerialized] (oops), so legacy files are holding on to a reference to the legacy Type for that class (through the serialized delegate).

I've implemented ISerializable on the renamed class in an attempt to avoid deserializing the PropertyChanged event, but that doesn't appear to have worked--an attempt to instantiate the old (renamed) class still occurs.

How do I force the BinaryFormatter to avoid attempting to deserialize delegates?

A: 

There is a reason why delegates CAN be declared OUTSIDE CLASSES.

Vercas
This isn't very helpful. I know that the PropertyChanged event should have been marked [NonSerialized]. It wasn't. I'm asking, now, if there's anything I can do to avoid breaking backward-compatibility with the poorly-designed serialized file.
TreDubZedd
+1  A: 

The solution, it appears, was to implement ISerializable on the class containing the reference to the Type, and to manually manage which fields were serialized, and how. This required that the refactored class leave a class stub in the original namespace for an intermediate build, in which we converted the legacy files to the new (refactored) format. Backward-compatibility cannot be recovered, but we were able to salvage the offending files.

TreDubZedd