I would like to get your advice on porting code from .NET to Mono. I have a
class library that I wrote for .NET 3.5 on Windows. In addition to working in
.NET on Windows I want to get it working in Mono on non-Windows platforms
(especially OS X on Intel chips.) This class library is currently about 90% C#
and 10% managed C++. The C# code is in one assembly and the managed C++ code is
in another assembly. The library has no GUI, but does make use of some
classes/methods that are not available/implemented in Mono. It also p/invokes
to
some Win32 APIs.
My initial thoughts on a plan for porting the code:
* If available replace each p/invoke to a Win32 API with a call to a
Mono
class/method providing similar functionality.
* If not available I plan to leave the p/invoke in place and build a
platform
specific native library (.dylib on OS X) providing similar functionality with
the same signature.
* Stub out or #ifdef out the code entirely. (For example the code that
ties in
to Windows event logging is not essential functionality.)
My initial thoughts on a strategy for porting the code:
* Port this library to Mono on Windows
* Port it to Mono on WINE on non-Windows platforms
* Port it to Mono on non-Windows platforms
My questions:
1. Aside from unavailable or unimplemented classes/methods in Mono and
p/invokes to native code what are some common gotchas when porting .NET code to
Mono?
2. Can Mono on Windows run managed C++ code?
3. Assuming the managed C++ code makes no platform specific calls, is
clean for
32/64 bit architectures, clean for bit endianness could it be recompiled can
Mono on non-Windows platforms run managed C++ code?
4. Would porting to Mono on WINE on OS X as an intermediate step be
worth the
effort?
5. Is there a better or alternative porting strategy that you would
recommend?
_______________________________________________
Mono-list maillist - [email protected]
http://lists.ximian.com/mailman/listinfo/mono-list
