The Mono Migration Analyser tool: is it really necessary? eWEEK Labs puts MoMA through its paces.
Using MoMA to Port from Windows .NET to Mono on Linux
When Microsoft originally released its .NET run-time and framework, programming for Windows became much easier. You got to choose from some favourite languages (C++, a Java-similar language called C# and Visual Basic), but by choosing .NET you were effectively locking yourself into the Windows platform. If you were thinking about portability, you had to look to such tools as C++ and wxWidgets.
That said, Microsoft did something right when it developed the .NET system. It devised a standard called the CLI (Common Language Infrastructure) that was accepted by both Ecma International and ISO (International Organisation for Standardisation). This allowed developers to create their own versions of .NET for other platforms, or even for Windows
A few groups of developers have worked on implementing CLI for other platforms, but the one that has clearly taken the lead is the open-source Mono Project. Mono is now available on Windows, the various breeds of Linux and Solaris, and even on Mac OS X – which means that Windows developers can port their software to any of these platforms.
Porting is still not perfect, however, as Microsoft continues to barrel forward with new APIs and technologies under the .NET umbrella. If you have an existing .NET project, you very well may run into problems trying to run it under the Mono run-time. And, indeed, you can run your .NET software directly under Mono, as the binaries are compatible—assuming you haven’t used any features not yet implemented under Mono.
That’s where the MoMA (Mono Migration Analyser) tool comes in. MoMA is available free of charge, as is the entire Mono project.
A MoMA Background
The MoMA tool is actually pretty small, there isn’t much to it. You simply specify a list of .NET binaries, and the tool will analyse them to look for calls into classes and functions that aren’t implemented by Mono, as well as calls directly into the operating system.
This might surprise you, as it did me. The tool analyses the binaries. At first this might seem a little odd that it’s doing some reverse engineering. But, in fact, the so-called binaries that run under the .NET CLI run-time are actually P-code stored in resources of executable files, these files are in turn known as assemblies.
Microsoft includes tools with its SDKs (software development kits) that make reverse-engineering your binaries a snap. The ILDASM (Intermediate Language Disassembler) tool easily opens up any CLI binary file and looks at the metadata describing the file, as well as at the actual assembly code.
However, this “assembly” code isn’t Intel assembly, rather, it’s the P-code, which is an assembled form of what is called IL (Intermediate Language), and this language is a much higher-level language than plain old assembly. This means it’s easy for the MoMA tool to open up your binary and do a full inspection of it – noting what libraries it calls and so on – without touching your source code.
Of course, if the tool finds problems, you’ll have to make the changes yourself, which means going back to your original source code and recompiling it. But if you think about it, thanks to the immediate code compiled to P-code, which follows a strict standard, it’s a lot easier for a tool such as MoMA to analyse binaries than to analyse source code that could be quite messy.