[Mono-dev] Re: Mono/.NET interoperability of System.Collections.Specialized

Miguel de Icaza miguel at ximian.com
Tue Oct 11 11:55:15 EDT 2005


> The compatibility of the inner representation of the Mono and .NET
> classes is very important, and, in some cases, we need to break API
> compatibility to achieve it. If a class is not implement ISerializable
> interface and it has different from .NET inner structure, we have a
> problem with interoperability, specially in remoting, where the server
> and the client can run on different machines with different runtimes.
> This problem raises not only in the System.Collection.Specialized
> namespace, and we should make a global decision about an our behavior in
> this case.

Am not sure that "to keep compatibility we must break compatibility" is
a good argument.  

If this is so important, then we might have to revisit the problematic
classes implementation and try to make it so it works with the field
names that the framework expects.   

But adding a public ISerializable sounds like a bad idea, currently am
thinking of code that the compiler would compile on Mono, but would not
on Windows, producing incompatible binaries. 

> This solution requires changes in the Mono's runtime.
> Another possibility is to change implementation of the class to be fully
> compatible with implementation in .NET. In the HybridDictionary class,
> for example, we should return the previous version of the class and
> treat Hashtable and List as two separate fields. Another alternative is
> to break the API compatibility and implement the ISerializable interface
> to manage the serialization info, as I made.
> What strategy is appropriate? Any other ideas?

Reimplementing the class to match the exposed internals would be the
best path in my opinion.


More information about the Mono-devel-list mailing list