[Mono-devel-list] un-interoperatible classes .NET -> Monoremoting
jason.king at profox.co.uk
Tue Sep 28 09:11:26 EDT 2004
I must state that I am not proposing any generic solution here. If
Aleksandar has a specific problem, I would suggest the middle layers
would strip out the relevant bits from the Mono side / Windows side and
put them into some Aleksandar specific class / collections etc.
I would think breaking down 'complex' classes such as hash tables and
arraylists into collection of simple arrays of objects would do the
trick. From an earlier mail, it seems the problem here is the
implementation / naming of fields in the classes in question.
Therefore, by looking at Mono source code (hey, its open source, you
could even change YOUR version to suit you / your remoting client) and
using the marvellous Reflector on Windows platforms, you would be able
to see where the hash table etc classes differ, and thus only wrap up
those that need it.
I would be surprised if you would have to convert string to char arrays
(I will take a risk: you don't need to!).
Co-Author, "Cross-Platform .NET Development: Using Mono, Portable.NET,
and Microsoft .NET"
(Apress, 2004, ISBN: 1-59059-330-8)
From: Anset [mailto:anset at anset.org]
Sent: 28 September 2004 13:18
To: Jason King
Subject: Re: [Mono-devel-list] un-interoperatible classes .NET ->
> As an alternative to compatibility problems, you could write two
> middle layers - one for each platform. MonoLayer will translate to
> and from a Mono implementation to your new common implementation, and
> MSLayer will do the same, but for MS implementations.
I assume these middle layers would "simplify" complex class objects like
array lists to their individual components? If so, how "low" does one
have to go to be guaranteed Mono <-> .Net interoperability?
Would a string also be guaranteed to work or would one need to use char
arrays? Only primitive (built-in) types? Only bits and bytes?
More information about the Mono-devel-list