Serialization and MobileFormatter futures

[rockfordlhotka]

This is a thread for discussing possible futures around serialization and/or MobileFormatter as we look forward.

As this thread starts there are several related backlog items already listed, but this thread isn't limited by them.

• Can't use Custom Formatter b/c CSLA hard-codes use of MobileFormatter in places #1297 (done: @rockfordlhotka)
• MobileFormatter should allow custom serializers for specific types #2531
• Reduce memory usage of MobileFormatter #2346
• CSLA, Source Generators, and Serialization #2154
• Enable serialization of POCO types via MobileFormatter #2148 (active: @TheCakeMonster)
• Consider creating a workaround for serialization of netfx ClaimsPrincipal #1877
• Add NonSerialized feature for managed backing fields #1628
• MobileFormatter and its reader/writer should be async #1376
• Investigate Serialization Refactoring and/or Restructing With Span<T> and/or Pipelines #1131
• Use object Identity as ref id in MobileFormatter #758

Please keep in mind that CSLA 5 is "done" and all work is now occurring for CSLA 6 or later.

[rockfordlhotka]

From another thread @bradtwurst says:

As I am attempting to migrate away from WCF and deal with a lot of POCO objects, I found my way here.

I found MobileFormatter very tough (frustrating) to deal with as it is sealed, locked-down, and is currently hard-coded in many of the portal implementations (although I do see that this last issue has changed in main branch).

While this may not be the ultimate solution, would it make sense to have an OnSerializing/Deserializing method hooks that could be utilized to allow the app developer to inherit from MF and tweak the logic.

I know that this wouldn't solve all the things, but it is a fairly straight-forward pattern that was used in other parts of the framework and it could be implemented in the current v5 release without breaking all the things.

If it sounds like an acceptable strategy, I'd be willing to invest some effort into this area as it is directly affecting my current focus.

James

One of the things @TheCakeMonster and I have been discussing over the past few weeks, is the idea of enhancing MF so it accepts a list of custom serializer types, where a serializer type knows how to serialize another type.

A scenario where this would be useful is a type that knows how to serialize POCO types, so you'd register it with MF and it would "somehow" identify which types it is willing to serialize (maybe via a custom attribute on the type or whatever).

Serializing arbitrary types is a potential security risk, which is why Microsoft has abandoned BinaryFormatter and NDCS. MF itself can only serialize types that opt-in to the process - you must code your type to participate in serialization, so the risk is not the same as BF/NDCS. I'd expect the same from any POCO serializer we build into the framework.

However, this ability to implement a custom type serializer would allow you to implement whatever you'd like in your own codebase - assuming your own risk.

You can imagine that a custom type serializer might implement an interface something like:

public interface ISerializeType
{
  bool CanSerialize(Type type);
  void Serialize(SerializationIinfo info, object target);
  object Deserialize(SerializationInfo info);
}

That's off the type of my head, but is the gist of the idea. MF itself would, for types it doesn't already understand, loop through the registered type serializers asking each whether it knows how to serialize the current type. If the answer is yes, MF will delegate serialization/deserialization to the type serializer. If the answer is no, MF will keep checking and eventually (if no match is found) throw the same serialization exception it does today.

[kcabral817]

There are a couple of types from MS Sql Server that might be considered for mobile formatter upgrade. I know of three at this time, DateTimeOffset, Geography and Geometry.

[rockfordlhotka]

The core Csla project won't take a dependency on any type that isn't in .NET itself - so no types from things like Microsoft.Data.SqlClient, etc.

What @TheCakeMonster and I have been discussing though, is a modification to MobileFormatter where you can provide a serializer for specific types. You'd register these serializers during app startup (via DI), and when MobileFomatter encounters one of these types, it would delegate the value to your serializer to convert it to/from a string (or byte array).

[TheCakeMonster]

Ah, yes. An excellent use case for the capability we were discussing. Good to have other real-world examples of what we are trying to add support for, thanks.

[rockfordlhotka]

I think that if we have MobileFormatter rely on a dictionary of <targettype, serializertype> that can be defined during app startup, and the dictionary injected to MobileFormatter (or something) that we'd have a good/flexible solution.

Then, if we want to use an attribute-based model, the attribute can be used to help load the dictionary, but also, types that can't be decorated with the attribute can be directly added to the dictionary during app startup.

[rockfordlhotka]

#2531