This is not how serialization works.
Theoretically speaking, it's quite possible to create serialization specifically with interfaces. To do so, you would need to create your own serialization mechanism.
This is possible, too. I can tell you what's involved. You can dig out what members are in each type involved using reflection. In particular, it will allow you to check up which interfaces are implemented, and which members are implementing interface members. Then you can get values of all properties/fields of primitive, string and enumeration types. For other types, you can recursively reflect their types. Ultimately, you can collect all the data from some object graph
and persist it the way you want. You can choose what part of data to persist and what not the way you want.
The trouble is: reflection is slow. You can greatly improve performance using
. This is how reflection implemented in .NET FCL works. When some data is serialized for the first time, a serialization assembly is created on the fly and is reused later. Writing Emit code is not so easy task. It requires good knowledge of IL and is hard to debug. Yes, I did it. Yes, for my own serialization system. Yes, it works, but I would like to improve it.
Would I advise you to do this job? My strong advice is: don't do it. Why? No, not just because programming with
is really difficult. Because your idea doesn't worth it. This is a bad, ad-hoc, non-flexible idea. However, you decide.
What would I advise? Use the well-working available mechanism instead: Data Contract
. Please see: http://msdn.microsoft.com/en-us/library/ms733127%28v=vs.110%29.aspx