Compiling for Mono
One of the main goals of Oxygene is to provide a solution that is 100% compatible with alternative implementations of the Common Language Runtime such as Mono. Our goal is to enable developers to seamlessly target all major CLR platforms, the Microsoft .NET Framework and Mono.
One of the steps to enable this is Oxygene's support for building applications for linking directly against Mono assemblies from within the Visual Studio IDE. This enables developers to use one familiar development environment to develop applications, whether cross platform or just for Mono.
In the long run, our plans also include integration with other .NET IDEs, including MonoDevelop.
Furthermore, the Oxygene compiler itself is also a fully managed application and as such capable to run under Mono, allowing you to use the command line compiler to build your projects on any platform supported by Mono, from Windows, Linux to Apple Mac OS X and others.
Oxygene comes with samples tailored especially for Mono, illustrating how to build both cross-platform as well as Mono specific applications, including using Gtk# and Cocoa# for Mac OS X.
Options for compiling against Mono
It is recommended that you use Mono 2.0 and later, not 1.0 and you have the following options:
- Run the Commandline Compiler under Mono.
- Run the compiler under .NET or inside Visual Studio and set the Framework Folder setting of your project to point to the Mono library folder.
To make this easier, as the version number and install path of Mono changes, Oxygene provides the {MONO} and {MONOFRAMEWORK} placeholders that can be used in the FramedworkFolder setting to refer to the default Mono framework folders.
When running the compiler under Mono, it will behave in the same way as the default (empty) framework setting, but when running under .NET on Windows, this will determine the Mono folder based on what/where the latest Mono runtime is installed (via a registry setting made by the Mono installer).
{MONO} refers to the base folder of all Mono assemblies (for example the C:\Program Files\Mono-2.0.1\lib\mono folder), while {MONOFRAMEWORK} refers to the 2.0 subfolder, which contains mscorlib and the System dlls.
- {MONOFRAMEWORK} is the best option to replace the .NET framework folder, when maintaining one project that you want to compile against both targets, as references such as $(Framework)\System.dll will work for both Mono and .NET compilation.
- {MONO} is well-suited for Mono-specific projects, when you need to access assemblies stored in parallel to the 2.0 folder, such as Gtk# or Cocoa# libraries. In this case, the core framework dlls need to be referenced as $(Framework)\2.0\System.dll. (note the extra 2.0 in the path).
The technique of building against Mono from a different platform is called Cross Linking.
Writing Cross-Platform Applications
In general, applications compiled with the normal .NET framework will deploy just fine for Mono, without special cross-linking. However, because certain differences exist between the two frameworks, it is recommended to test building against Mono once in a while (even if you won?t use that version for deployment). The simplest way to do this is to simply add an additional ?Mono? configuration to the project and use the above {MONOFRAMEWORK} as the setting for the Framework Folder setting of this config.
Of course, when writing non-cross-platform applications just for Mono, linking to the Mono dlls will also give you full access (compiler and IDE intellisense) to Mono-specific classes (such as the Mono.* namespace, Gtk#, etc.).
Debugging Mono Applications
- Debugging Mono applications in Visual Studio or Cordbg.
Debugging will work in general - you can run Mono applications in the debugger, set breakpoints, etc. There is one important limitation of which you should be aware, in that the debugger will always load the MS version of mscorlib.dll, and run your application under Microsoft's .NET runtime, not Mono's. If you use Mono-specific types from mscorlib.dll, the applicatio will fail, but if your Mono applications can handle running with the Microsoft version of that dll, most the other Mono dlls (such as Gtk#) load fine in the debugger and you can run and test your applications.
Note that some technologies might not be supported under Windows at all, and thus cannot be debugged. For example the Cocoa# and related libraries work against native Mac OS X user interface libraries that do not exist on Windows, so Cocoa# based code cannot be run or debugged on a Windows machine. Gtk# is supported fine on Windows however , so the above will work for Gtk# applications.
- Using GTK-Sharp from within Visual Studio
GTK requires several dlls that are not in the system path by default. There are two ways around this: the first and easiest option is installing the Standalone GTK Installer; another option is adding the path to mono/bin to the system path so the system will be able to find them.
- Debugging Mono applications in Mono.
Oxygene can generate .MDB debug symbols files for use with the mono debuggers (see Project Options - Build), when the compiler is running under Mono 1.1.x or later. If running under Mono 1.0 or under .NET (i.e cross linking), MDBs cannot be generated.
Mono/XSP
You need at least Mono 1.1.8 to fully run ASP.NET applications under Mono?s XSP. There are certain bugs that were fixed for us in 1.1.8, that prevented some pages from running (though most asp.net applications run fine with older mono versions). We recommend using at least version 2.0.1 or later.
See Also
