Different serialization options have different features and trade-offs. There is no one option that does everything you want, because:
- not everything is
[Serializable]
(forBinaryFormatter
) - plusBinaryFormatter
is virtually always a bad choice - not everything has a public parameterless constructor suitable for
XmlSerializer
- and so on, for every serializer you can name (and trust me, I can name plenty): they all have different features and things they can/can't do - usually with good protocol reasons, not just apathy / incompetence
IMO, the problem here is that you are trying to serialize implementation details rather than serializing data. If you create a custom DTO model that just represents the data (but which has no dependency on 3rd-party types) then it will be possible to create a sane serialization model that works very efficiently with your choice of serializer, and which doesn't break horribly when you upgrade a library reference, or switch to a different library completely.
Some serializers (protobuf-net does, certainly) allow you to mix and match by way of serialization surrogate types, meaning you can tell it to silently substitute some types when it encounters them (in particular, if 80% of your model is serialization-friendly, this lets you swap out the other 20% as part of the engine) - but without knowing more about the specifics here it is hard to say whether that will help.