mono-api-embedding.html
Embedding Mono
mono_jit_init
Prototype: mono_jit_init
mono_set_dirs
void
mono_set_dirs (const char *assembly_dir, const char *config_dir)
Parameters
assembly_dir: the base directory for assembliesconfig_dir: the base directory for configuration files
Remarks
This routine is used internally and by developers embedding
the runtime into their own applications.
There are a number of cases to consider: Mono as a system-installed
package that is available on the location preconfigured or Mono in
a relocated location.
If you are using a system-installed Mono, you can pass NULL
to both parameters. If you are not, you should compute both
directory values and call this routine.
The values for a given PREFIX are:
assembly_dir: PREFIX/lib
config_dir: PREFIX/etc
Notice that embedders that use Mono in a relocated way must
compute the location at runtime, as they will be in control
of where Mono is installed.
mono_runtime_exec_main
Prototype: mono_runtime_exec_main
mono_runtime_exec_managed_code
Prototype: mono_runtime_exec_managed_code
mono_jit_cleanup
Prototype: mono_jit_cleanup
mono_set_defaults
Prototype: mono_set_defaults
Internal Calls
The Mono runtime provides two mechanisms to expose C code
to the CIL universe: internal calls and native C
code. Internal calls are tightly integrated with the runtime,
and have the least overhead, as they use the same data types
that the runtime uses.
The other option is to use the Platform Invoke (P/Invoke)
to call C code from the CIL universe, using the standard
P/Invoke mechanisms.
To register an internal call, use this call you use the
mono_add_internal_call routine.
Data Marshalling
Managed objects are represented as MonoObject*
types. Those objects that the runtime consumes directly have
more specific C definitions (for example strings are of type
MonoString *, delegates are of type
MonoDelegate* but they are still MonoObject
*s).
As of Mono 1.2.x types defined in mscorlib.dll do not have
their fields reordered in any way. But other libraries might
have their fields reordered. In these cases, Managed
structures and objects have the same layout in the C# code as
they do in the unmanaged world.
Structures defined outside corlib must have a specific
StructLayout definition, and have it set as sequential if you
plan on accessing these fields directly from C code.
Important Internal calls do not provide support for
marshalling structures. This means that any API calls that
take a structure (excluding the system types like int32,
int64, etc) must be passed as a pointer, in C# this means
passing the value as a "ref" or "out" parameter.
mono_add_internal_call
Prototype: mono_add_internal_call
Mono Runtime Configuration
Certain features of the Mono runtime, like DLL mapping, are
available through a configuration file that is loaded at
runtime. The default Mono implementation loads the
configuration file from $sysconfig/mono/config
(typically this is /etc/mono/config).
See the mono-config(5) man page for more details
on what goes in this file.
The following APIs expose this functionality:
mono_config_parse
void
mono_config_parse (const char *filename)
Parameters
filename: the filename to load the configuration variables from.
Remarks
Pass a NULL filename to parse the default config files
(or the file in the MONO_CONFIG env var).
mono_config_parse_memory
void
mono_config_parse_memory (const char *buffer)
Parameters
buffer: a pointer to an string XML representation of the configuration
Remarks
Parses the configuration from a buffer
Function Pointers
To wrap a function pointer into something that the Mono
runtime can consume, you should use the mono_create_ftnptr.
This is only important if you plan on running on the IA64
architecture. Otherwise you can just use the function
pointer address.