Free! - CompactFormatterPlus: Generic Serializer

The advent of .Net framework is the most significant event in the programming world over the last 10 years and I think it is still underestimated. It is the most solid and comprehensive framework ever. However nothing and nobody is perfect. This article is about .Net framework communication and compact framework communication (serialization) in particular.

Total recall

.Net standard communication suffers from the same disease that Windows OS suffered 10 years ago. Core Windows API is same as it was 10 years, but the programming of Windows Form Application 10 years back was a serious ordeal. Why? Because the programmer had to provide all the parameters manually. In order to provide all the parameters, he needed to know all Windows internals and how to use them. In .Net environment all the defaults are set by the framework. We drag the controls from the toolbox and the rest is done automatically. If we need extra features, we can select them from the property grid or type them in the code.

In the real life we send the object (the letter or the parcel) to the recipient. Do we really care how the letter is delivered, what is the postman's name or the name of his pet dog? No, we don't. Usually we drop the letter in the postbox and the rest is done by default. If we want some extra features, like better security or delivery confirmation, we can get that as an extra. If the letter delivery looked like .NET communication (WCF in particular), the procedure of the letter delivery would have certainly been like that: we select from the catalog the number plate of the car that carries the letter, the name of the driver, the flight number, the type of the plane, envelope color, brand … Most probably that would stop us from sending the letter at all.

Alternatives

While high priests of IT industry keep saying that everything is better than ever, the communication frameworks (mostly .Net socket based) keep multiplying.

Codeproject website hosts at least 10 of them. The design of a primitive communication class with a limited functionality (often it is enough) is not too hard, but the major showstopper was a serializer, specifically for the Compact Framework.

Compact framework remoting

Unfortunately Remoting and Binary formatter is not implemented (and apparently will not be) for the compact framework. The only choice is using limited XMLSerializer (which is not generic) and the implementation of the system where you can simply drop the object on one side and get it on the other is not technically possible. Apart from the serializer other components like channels or threads are readily available in CF.

Compact framework serialization

CompactFormatterPlus : Generic Binary Serialilzer for Compact Framework

This work is based on a brilliant Angelo's Scotto CompactFormatter for the full and Compact Framework. The original CompactFormatter was written for .Net 1.1

However the years went on and the opportunities for the improvement emerged. Basically the reasons for the redesign are:

1. Compact Framework 2.0 has serializable attribute. This attribute was introduced only for compatibility with a full framework. Other than that the practical value of this attribute is questionable because the classes built prior this attribute was introduced obviously do not have it. And solely relying only on this attribute will make quite serializable classes nonserializable. Original CompactFormatter has similar attribute but it is not compatible with full framework. Checking for this attribute (Angello's serializable atribute) was removed. It made the classes created for the full framework and compact framework compatible. Though it has some drawback – totally nonserializable objects will be attempted to serialize.

2. Serialization of the DataSet and DataTable in CompactFormatter is not full. DataSet serialization designed by SimmoTech is far more advanced. Simotech serialization and the code can be found in the Codeproject article http://www.codeproject.com/dotnet/OptimizingSerialization2.asp. This code was incorporated into CompactFormatter as a surrogate.

3. For the performance reasons the original CompactFormatter puts the indexes of the classes in the stream instead of the class name. That is good if the serializer exists consistently during the communication session. Practically that is not always the case. The serializer may be instantiated dynamically and CompactFormatter certainly fails.

4. The way the classes are instantiated when deserialized: CompactFormatter uses incomplete assembly name or fully qualified assembly name. Either method fails if the communication platforms are different. For instance fully qualified assembly name is meaningless when the object is serialized on full framework and deserialized on the compact. Only the primitive types and the types defined within the serializer will work.

5. Automatic surrogte generation tool can be used now for the surrogates.