Binary Serialization - Need Advice on How To Prevent DevelopersAccidentally Breaking Serializations

[Shalom Shachne]

Hi all,

We have an object graph that we persist to disk using binary
serialization. The issue that we are trying to find a solution to, is
how to prevent developers from accidentally breaking serialization, by
adding a new object to the graph which is not serializable.

I was hoping to add a Nunit test to our suite which would fail if this
object graph is not serializable. However, after having done this
once in Java, I realized it is not so straightforward.

(In Java, if your object contains another object which is not
Serializable, it won't fail if the child object is null at time of
serialization. So our unit test had to use Reflection to iterate over
the public and private fields of the entire object graph to test that
each member implemented Serializable).

I'm wondering if, in .NET there is some easier way to test that the
entire object graph is serializable? (If the solution is have your
test populate every field with data, and then try to Serialize, we
might as well follow the same model as we did for the Java code).

Thanks for anyone's thoughts on this...
Sam

 

[Peter Duniho]

Hi all,

We have an object graph that we persist to disk using binary
serialization. The issue that we are trying to find a solution to, is
how to prevent developers from accidentally breaking serialization, by
adding a new object to the graph which is not serializable.

I was hoping to add a Nunit test to our suite which would fail if this
object graph is not serializable. However, after having done this
once in Java, I realized it is not so straightforward.

(In Java, if your object contains another object which is not
Serializable, it won't fail if the child object is null at time of
serialization. So our unit test had to use Reflection to iterate over
the public and private fields of the entire object graph to test that
each member implemented Serializable).

I'm wondering if, in .NET there is some easier way to test that the
entire object graph is serializable? [...]

Assuming your object graph is not determined statically, I can't imagine
how it could even be possible to test without a run-time enumeration of
the graph. And even if you use reflection to check type implementation of
an interface or code attribute for objects in the graph, that can only
tell you about the variable (class member field or property) you found in
the graph; it won't tell you anything at all about variables that might be
contained in a non-null instance of a type used in the existing graph at a
point where the variable was null at the time of enumeration.

In other words, even using Reflection, it's not all that straightforward a
task. It seems to me that what you really need to do is to start with the
type of the root of your graph, and then for every object that could
possibly be referenced as that type, examine every serializable variable
in that type (note that in .NET, not every member of every type is
necessarily serialized), applying the same algorithm (i.e. check every
type that could possible be referenced as the type of that variable). And
you'll have to maintain a dictionary or something of each type you've
already inspected, to avoid dealing with cycles in the graph.

And if you have no way to reliably know for sure every type that could be
used in a particular variable in your graph (e.g. you've got a variable
typed as Object but which could be serialized), then you can't even apply
that kind of logic. You'd have to add some kind of way to represent what
types actually might be used in that variable (e.g. define a new custom
code attribute).

It seems to me that at the most, what you might consider doing is to
create a sort of "gate-keeper" method for use in adding objects to the
graph, and which checks each object added to ensure it's serializable.
And from a practical point of view, it may be that you simply include in
your checklist of "things to test after adding code" the requirement to
test serialization, so that developers always verify that when they add
new object types to your graph, those object types do in fact serialize
properly.

Pete