Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Migrating Established Code From .Net to Mono

Migrating Established Code From .Net to Mono

This item in japanese

A legacy application code base represents a significant investment of time and money for a developer. Ideally the existing code can easily be combined with some platform specific glue that will produce a quick turnaround that leverages the original investment. In practice such re-targeting may not be always that easy, so the recent article, “Real world feedback on a .Net to Mono migration” by Patrick Smacchia is a useful report on his experience migrating existing .Net code to the Mono platform.

Smacchia describes his company's recent efforts to migrate his original product NDepend – written for the .Net platform– to produce a new product, JavaDepend, which is designed to run on Mono under both Windows and Linux. Overall he considers the effort very successful and the use of the Mono platform contributed to an estimated reuse of 90% of the existing code base.

Notably, a few features were instrumental in the ease of the platform migration. Mono's Migration Analyzer (MoMA) was used to locate both platform specific code and code using .Net features not yet supported by Mono. As described on its homepage, the Migration Analyzer may generate some false positives, and will not catch all potential issues. However Smacchia was pleased with the MoMA's performance. The biggest problem area MoMA identified was in relation to a third party GUI library used by NDepend. Rather than be forced to maintain separate GUI tracks for the Windows and Linux versions, the developers chose to utilize wrapper classes which could map the proprietary GUI code to standard .Net components.

Smacchia had high praise for Mono's GDI+ support, emphatically stating “[that] the Mono implementation of GDI+ did the job! Bravo! I really have to [congratulate] the Mono team...” Finally there were a couple of Windows Form components (DataGridView/ListView and RichTextBox) that produced erratic behavior under Mono. The open source nature of the Mono project allowed the developers to make the specific changes they needed without relying on a official Mono release to correct the problems.

Rate this Article