[Mono-dev] Re moting between dotnet framework and mono framework

Robert Jordan robertj at gmx.net
Thu Mar 12 11:00:56 EDT 2009


lionel.cuir at aulofee.com wrote:
> Hi,
> To Robert Jordan: you said: "You can expect 100% compatibility with custom
> classes (those you've designed yourself). Basic BCL classes (ArrayList,
> Hashtable) are also compatible, but it's safer to not depend on classes that
> are not under your control."
> Has there been any advance on this area since 1 year? As for me (but please
> correct me if needed), there are still basic BCL classes whose binary
> serialization is not compatible between Mono and .Net. Ex: Dictionary<K,V>

Dictionary<K,V> should be compatible up to this bug for which a patch
already exists: https://bugzilla.novell.com/show_bug.cgi?id=474009

> (well, you may say that it's not a bscic BCL class...), there is/was also
> the problem on DateTime, depending on the way you serialize it (see
> https://bugzilla.novell.com/show_bug.cgi?id=325067).

This problem was discussed to death in the past, as you can
read in Bugzilla ;)

> To Eric: since Mono developpers did not have access to MS's spec (and didn't
> disassemble any code), only the public members of BCL classes were guaranted
> to be the same - private fields can be whatever the developer wanted. So
> many classes have a binary format 100% compatible between both platforms,
> but some not. In my company, we are transfering data in binary format
> between Mono and .Net and, from our experience, you have to test (what some
> Mono developers pitifully didn't do - nobody is perfect).

Well, there is no shortcut for checking serialization compatibility
other than building serialization unit tests for all involved classes.

For interoperability tests, binary blobs have to be maintained and
fed to several mono and MS.NET versions during "make check".
This is a huge effort no one was willing to take on.

OTOH, bugs were usually fixed in a timely manner when we got proper
reproducible reports and if the bug was fixable w/out negative
versioning effects.


More information about the Mono-devel-list mailing list