Yesterday I received an email from a support person that manages a software I created and that's installed in several customers.
At first, the problem seemed really strange, and happened in a place inside the application that was tested several times before.
To put a little background on this software, it's a DMS (Document Management System) built with the .NET Framework v4.0, and uses remoting as the communication method between client and server components.
The exception was thrown when trying to update an object of type Application (not the Windows.Forms.Application, but a custom one) via a remoting call. That call was something like:
oBL.UpdateApplication(app)
The exception thrown was:
System.Runtime.Serialization.SerializationException - The type<br />
System.Windows.Forms.CurrencyManager in Assembly System.Windows.Forms,<br />
Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 is not<br />
marked as serializable.
The oBL object is a remoting proxy of a server object, and app is a custom assembly class that needed to be refreshed after the information was updated.
The app object contains primarily a bunch of properties of basic types (strings, integers, etc) and collections of other assembly types.
The exception tracking process
It was clear that there was some property inside the app object that didn't like to be serialized (now). So I decided to run the software in Visual Studio and debug it.
I started a step debug, nulled out the app properties one by one and retried the remoting call, until the exception wasn't raised. After a while I found the culprit.
It was a collection-based property called ValueListList (a list of ValueList objects). The base type of this collection was marked as serializable, but the problem was in an interface implementation.
The original ValueListList implemented the IList interface but since this lists needed to be bound to UI controls, some time ago I decided to replace the IList by an IBindingList implementation.
The IBindingList interface declares a ListChanged event... now you get the picture, don't you?
An event? ... With remoted objects? ... Hmm..smells bad.
Whenever an object gets bound to a UI control, the framework uses the CurrencyManager (for object collection properties) or a PropertyManager (for simple properties) to handle databinding between the controls and the source object.
The CurrencyManager is not a serializable class. When the ValueListList class is bound to a UI control, an instance of CurrencyManager is attached to the event delegate. Then, when a remoting call is attempted to pass the app object to the server, the remoting framework parses the object tree and serializes the graph. When the CurrencyManager is reached, boom! ... SerializationException!
The (simple) solution
After some head scratching, I tried one thing that worked seamlessly. The event declaration in the class now looks like this:
<NonSerialized()>Public Event ListChanged(ByVal sender As Object, ByVal e As ListChangedEventArgs) Implements IBindingList.ListChanged
The addition of the NonSerializedAttribute to the event resolved the remoting serialization problem. Now the application object can be passed from client to server without nasty exceptions happening in between, because the event (and it's attached listenters/objects including the CurrencyManager) is not touched by the remoting serialization process.
CodeProject
