[Mono-dev] A significant number of Mono classes are not (binary) compatible with their .Net equivalents?

[Robert Jordan]

Hi,

> It seems there are many many classes in Mono that are not fully 
> compatible - to be more precise binary compatible - with their 
> equivalents in the .Net framework (the fact you work with Mono on Linux 
> or Windows does not matter). By binary compatible, I mean to binary 
> serialize a class in Mono and to deserialize in .Net, or vice-versa. 
> This is a simple but much needed need when two systems must communicate 
> with each other (over network or with file exchange).
> 
> To give some figures, I've created a sample test application and ran it 
> on System.dll: over 430 types, approx. 68 instantiated and serialized 
> with .Net throw an exception when deserialized with Mono.
> 
> Where does the problem come from?
> Binary serialization works by creating an internal dictionary which 
> stores the names of the object's serialized fields and their values. At 
> deserialization, we use the names in the tables, matchs them against the 
> name of the class of the framework (Mono or .Net) and restore the value.
> 
> The problem is simple but concrete: .Net and Mono developers have not 
> use the same name for their fields. Hence the exceptions thrown.

The problem is not simple at all. Mono's developers didn't
decompile MS.NET. They've implemented the classes from reading
the docs of the public API. Since serialization is reflecting on
private members, it is inherently very implementation specific.

You may have a look at the System.Drawing.Color class to
see what a mess serialization could be when the implementation
details differ too much.

> Once more, I sincerely hope that I'm misleading somewhere, because I 
> don't think the review of all that classes is anybody's cup of tea...

You got this right, although you seem to test the .NET 2.0 API
which is still incomplete and still in development.

Note that serialization is problematic in general, even on MS.NET
(just try to deserialize data written by 2.0 with an 1.1 application).
My strong opinion (regardless of the framework) is to not rely on
serialization for types you didn't implement yourself, excepting
some basic corlib types like collections.

Robert