Mono linux ��� ��������

Guide:Running Mono Applications

Table of contents

Basic usage

The normal way to run an application you have compiled with Mono would be to invoke it through the Mono runtime, like this:

Mono includes two execution systems:

• one is based on an advanced code generator (with the mono command); and
• one, older and unsupported, is based on an interpreter (the mint command).

With the mono JIT default, not all optimizations are turned on, since some of them can be quite time consuming. However, when using it in batch mode, it is recommended that you use the -O=all switch to improve the code generation, for example:

The above will leave the native version of the code in `library.dll.so’. See the page on AOT for more details.

Shell Scripts

However, there are two things you can do to make it more convenient to run Mono applications. The first is to use a shell script instead of the EXE file. For example, if you had “myprogram.exe” you could create a shell script called “myprogram” that had the contents:

When you run “myprogram,” the shell will replace $@ with any arguments you provided.

If you installed mono to a different location, substitute that for /usr/bin/mono. You can check with the “which mono” command.

Registering .exe as non-native binaries (Linux only)

Because this is a Linux-specific feature, we do not recommend that developers deploy this solution, as it would limit the portability of their scripts.

In addition, this mechanism does not work as intended by the Application Deployment Guidelines.

You can also make a systemwide change, and use binfmt to register the exe files as non-native binaries. Then, when trying to launch an exe file, the kernel will run the mono interpreter to handle the command. Binfmt can also be used to launch Windows executables using WINE, or Java .class files using a JVM. To register exe with the kernel:

• Become root and turn on the binfmt module in your kernel with this command:

In addition, you may want to add that command to your /etc/rc.local boot script, so that it will be executed on boot.

• Add the line below to your /etc/fstab file:

• Then, have your system run the following command on boot:

• Be sure to mark your .exe files as executable in the filesystem as well:

Note that this doesn’t change your kernel, just the modules that it loads when you boot your system. In other words, you can still upgrade your kernel without worrying about losing these changes. Similarly, you can upgrade your Mono runtime without affecting any of the invocation methods listed in this section.

Bundles

mkbundle generates an executable program that will contain static copies of the assemblies listed on the command line.

By default only the assemblies specified in the command line will be included in the bundle. To automatically include all of the dependencies referenced, use the “–deps” command line option.

For example, to create a bundle for hello world, use the following command:

The resulting executable is self contained and does not need the Mono runtime installed to run. However, if your application relies on libraries linked to by the mono runtime or Gtk#, those will need to be installed (Gtk# helper libraries come to mind).

An example with a slightly more complex application (with the same mkbundle options) which uses Gtk# and misc assemblies:

The -z option allows you to compress the assemblies included in the bundle, and reduce the disk space consumed.

The -c option will create a host.c file which contains the main function of the program, which you can modify before compiling and linking the application.

With -c, the further option –nomain will generate the host.c file without a main method so that you can embed it as a library in an existing native application in which you are embedding the Mono runtime yourself. Just call mono_mkbundle_init() before initializing the JIT to make the bundled assemblies available.

Bundles in addition support a –static flag. The –static flag causes mkbundle to generate a static executable that statically links the Mono runtime. Be advised that this option will trigger the LGPL requirement that you still distribute the independent pieces to your user so he can manually upgrade his Mono runtime if he chooses to do so. Alternatively, you can obtain a proprietary license of Mono by contacting Xamarin.

Источник

The Mono Runtime

The Mono runtime implements the ECMA Common Language Infrastructure (CLI). The Mono runtime implements this virtual machine.
If you are interested in the technical aspects of the Mono runtime check the Runtime Documentation.

The runtime offers the following services:

• Code Execution
  • Code loading
  • Support for dynamically generating code
  • On-the-fly marshalling to invoke native methods.
  • COM Interoperability
• Garbage Collection, using one of:
  • Precise SGen Garbage Collector
  • Conservative Boehm Garbage Collector
• Code Generation
  • Just-in-Time compilation, partial and full Ahead-of-Time modes
  • Backend engines:
    • Mono’s own engine
    • LLVM optimizing compiler backend engine
  • First-class SIMD datatypes (Mono.Simd)
• Exception Handling
  • Software-triggered exceptions
  • Hardware-triggered exceptions like Floating point exceptions, null reference exceptions
• Operating system interface
  • File system IO
  • Networking IO
  • Access to operating system properties and features
  • On Unix systems, Mono.Posix APIs
• Program isolation using Application Domains (AppDomain)
• Thread management:
  • Threadpool for user code
  • Threadpool for networked IO
  • Asynchronous method invocation
• Console access
• Security System

The Mono runtime can be used as a stand-alone process, or it can be embedded into applications

Embedding the Mono runtime allows applications to be extended in C# while reusing all of the existing C and C++ code. For more details, see the Embedding Mono page and the Scripting With Mono page.

Supported Platforms

Mono has support for both 32 and 64 bit systems on a number of architectures as well as a number of operating systems.

Supported Operating Systems

Operating Systems

Supported Architectures

Supported Architectures	Operating system
s390, s390x (32 and 64 bits)	Linux
SPARC (32)	Solaris, Linux
PowerPC	Linux, macOS, Wii, PlayStation 3
x86	Linux, FreeBSD, OpenBSD, NetBSD, Microsoft Windows, Solaris, macOS, Android
x86-64: AMD64 and EM64T (64 bit)	Linux, FreeBSD, OpenBSD, Solaris, macOS
IA64 Itanium2 (64 bit)	Linux
ARM: little and big endian	Linux (both old and new ABI), iPhone, Android
Alpha	not maintained. Linux
MIPS	Linux
HPPA	not maintained Linux

Note that the Alpha, MIPS, ARM big-endian and HPPA architectures are community-supported and may not be as complete as the other architectures.

Support for SPARC64 works in older versions of Mono, but not in the recent versions.

Packages for most platforms are available from the Downloads page.

Embedded systems

To make mono more suitable for some architectures used as embedded systems have a look at the Small footprint page.

Compilation Engine

Paolo Molaro did a presentation on the current JIT engine and the new JIT engine. You can find his slides here.

We have re-written our JIT compiler. We wanted to support a number of features that were missing: Ahead of Time compilation, simplify porting and have a solid foundation for compiler optimizations.

Ahead-of-time compilation

The idea is to allow developers to pre-compile their code to native code to reduce startup time, and the working set that is used at runtime in the just-in-time compiler.

Although in Mono this has not been a visible problem, we wanted to pro-actively address this problem.

When an assembly (a Mono/.NET executable) is installed in the system, then it is possible to pre-compile the code, and have the JIT compiler tune the generated code to the particular CPU on which the software is installed.

This is done in the Microsoft.NET world with a tool called ngen.exe.

The code produced by Mono’s ahead-of-time compiler is Position Independent Code (PIC) which tends to be a bit slower than regular JITed code, but what you loose in performance with PIC you gain by being able to use all the available optimizations.

To compile your assemblies with this, just run this command:

The above command will turn on all optimizations ( -O=all ) and then instructs Mono to compile the code to native code.

Additionally, if you want to do full static builds (and be able to run without the JIT engine), you can use:

Then you can configure your Mono runtime with –enable-minimal to remove the JIT engine. This is useful on systems that do not support Just-in-Time compilation at the kernel level.

Some features like Reflection.Emit and other forms of dynamic code generation are not support in this scenario.

Notice that for Mono 2.0 generics are not supported when doing full-AOT.

Some optimizations are being planned: OptimizingAOT

Bundles

Mono also offers bundles. Bundles merge your application, the libraries it uses and the Mono runtime into a single executable image. You can think of bundles as “statically linking mono” into your application.

To do this, you use the “mkbundle” command (see the man page distributed with Mono for more details).

For example, to create a fully static and bundled version of Mono for “hello world”, you would:

Of course, you can also just embed the libraries, without the actual Mono runtime, by removing the –static flag.

Linker

Mono ships with a customizable assembly-linker. This is a technology that can be used to create a custom deployment of the Mono runtime that only contains the code that your application uses. This is similar to what a native linker does, except that we retain the same assemblies.

You can combine the output of the linker with the bundler. Allowing you to produce smaller versions of your self-contained executables.

Platform for Code Optimizations

Beyond the use of the Mono VM as Just-in-Time compiler, we need to make Mono code generation as efficient as possible.

The design called for a good architecture that would enable various levels of optimizations: some optimizations are better performed on high-level intermediate representations, some on medium-level and some at low-level representations.

Also it should be possible to conditionally turn these on or off. Some optimizations are too expensive to be used in just-in-time compilation scenarios, but these expensive optimizations can be turned on for ahead-of-time compilations or when using profile-guided optimizations on a subset of the executed methods.

Simplify Porting

We wanted to reduce the effort required to port the Mono code generator to new architectures.

For Mono to gain wide adoption in the UNIX world, it is necessary that the JIT engine works in most of today’s commercial hardware platforms.

The new Mono engine now supports both 32 and 64 bit systems and various architectures (See Supported Platforms).

Profiling and Code Coverage

Mono provides a number of profiling tools and code coverage tools.

See the Performance Tips page for details on using the profiler, and the Code Coverage page for information on how to use the code coverage functionality with your application and your test suites.

DTrace

Mono’s support for DTrace is available on Solaris and macOS.

Logging runtime events

Versioning

Mono supports a Global Assembly Cache or GAC. The GAC is used to share libraries between different applications, to keep multiple versions of the same library installed at once and to avoid conflicts over the names of the libraries and they also play an important role in trust and security.

See the Assemblies_and_the_GAC document for more details.

Garbage Collection

Mono today uses Boehm’s GC as its Garbage Collection engine. We are also working on a precise and compacting GC engine specific to Mono.

The GC interface is being isolated to allow for more than one GC engine to be used or for the GC to be tuned for specific tasks.

Mono’s use of Boehm GC

We are using the Boehm conservative GC in precise mode.

There are a few areas that the GC scans for pointers to managed objects:

1. The heap (where other managed objects are allocated)
2. thread stacks and registers
3. static data area
4. data structures allocated by the runtime

(1) is currently handled in mostly precise mode: almost always the GC will only consider memory words that contain only references to the heap, so there is very little chance of pointer misidentification and hence memory retention as a result. The new GC requires a fully precise mode here, so it will improve things marginally. The details about mostly precise have to do with large objects with sparse bitmaps of references and the handling of multiple appdomains safely.

(2) is always scanned conservatively. This will be true for the new GC, too, at least for the first versions, where I’ll have my own share of fun at tracking the bugs that a moving generational GC will expose. Later we’ll conservatively scan only the unmanaged part of the stacks.

(3) We already optimized this both with Boehm and the current GC to work in precise mode.

(4) I already optimized this to work in mostly precise mode (ie some data structures are dealt with precisely, others not yet). I’ll need to do more work in this area, especially for the new GC, where having pinned objects can be a significant source of pain.

References

Garbage collection list and FAQ: http://www.iecc.com/gclist/

“A Generational Mostly-concurrent Garbage Collector”:

Details on The Microsoft .NET Garbage Collection Implementation:

IO and threading

The ECMA runtime and the .NET runtime assume an IO model and a threading model that is very similar to the Win32 API.

Dick Porter has developed WAPI: the Mono abstraction layer that allows our runtime to execute code that depend on this behaviour, this is called the `io-layer’ in the Mono source code distribution.

This io-layer offers services like named mutexes that can be shared across multiple processes.

To achieve this, the io-layer uses a shared file mapping across multiple Mono processes to track the state that must be shared across Mono applications in the

Useful links

See our Papers section for various articles describing virtual machines and JIT compilers.

Porting

See the Porting page for more details on porting Mono to a new platform.

Projects Under Development

There are a number of projects being developed in branches or on separate trees for the runtime, these are:

• Runtime Projects: General Runtime Projects.
• Runtime Requests: Ideas of things that we could use to improve Mono’s runtime.
• Compacting GC: A generational, compacting GC for Mono.
• JIT Regalloc: A new register allocation framework.
• Mono_Runtime_API_Changes: Changes that will be introduced in Mono 2.8.

• Continuations: Support for co-routines and continuations in Mono.
• SafeHandles: Support for 2.0 SafeHandles.
• Linear: An update to the JIT’s internal representation (IR).

COM and XPCOM

Mono’s COM support can be used to interop with system COM components in Windows and in Linux (if you use a COM implementation). Additionally, Mono’s COM support can be used to access software based on Mozilla’s XPCOM.

For details on the progress, see the COM Interop page.

Источник