Csla 4.0.0.0 - MyCustomMobileFormatter

[BPJDeLozier]

== QUESTION ==
How do I use MyCustomMobileFormatter with Csla 4.0.0.0?
OR
Other solutions to my issue (still using Csla 4.0.0.0).

== My Issue ===
Project_Dto references Csla 4.0.0.0

ProductA_ServerApp references Project_Dto
ProductA_ClientApp references Project_Dto

ProductB_ServerApp references Project_Dto
ProductB_ClientApp references Project_Dto

ProductA and ProductB are related and thus Project_Dto have objects that are shared between the two.

It might be the case that ...
When ProductA version 1.0 was compiled, Project_Dto had a version of 1.0
Then ProductB version 5.0 was compiled and Project_Dto's version was changed to 5.0
THEN a patch for ProductA ClientApp is necessary, BUT, Project_Dto is now version 5.0

I would like ProductA ClientApp using Project_Dto version 5.0 to still be able to communicate with ...
... ProductA ServerApp using Project_Dto version 1.0
... as long as the contracts are the same (the only difference is Project_Dto's version)

The default formatter MobileFormatter cares that the versions are different between the Client and Server despite the contracts being the same.

If I could inject MyCustomMobileFormatter into the Serialization / Deserialzation I think I could make it ignore versions
Of Course, if there is a better way than even overriding the formatter, I'm open to suggestions.

[rockfordlhotka]

If I understand correctly, you have created your own version of MobileFormatter and you are using that as the serializer instead of MobileFormatter?

I think that we added an option to a later version of MobileFormatter so it can ignore the version number in the fully qualified type names. You might choose to use a later version of CSLA to solve the issue.

There was a long period of time where it was essentially unrealistic to replace the formatter, because I'd hard-coded the use of MobileFormatter in a number of places in the codebase. That was unfortunate, and is also something that has been addressed in more recent versions.

However, iirc, there is still an issue in UndoableBase where a type that can't be identified as serializable by other means is still serialized by MobileFormatter. I'm pretty sure there's an open issue to resolve this.

I suspect that, for you to use a custom serializer in CSLA 4, you'll have to fork and fix the old codebase to:

1. Eliminate all hard-coded uses of MobileFormatter so the formatter comes from the serialization factory like it was supposed to in the first place 😳
2. Find and fix the issue I'm talking about in UndoableBase