cli man page on ElementaryOS

Man page or keyword search:  
man Server   4994 pages
apropos Keyword Search (all sections)
Output format
ElementaryOS logo
[printable version]

Mono(Mono 3.0)							Mono(Mono 3.0)

       mono  -	Mono's ECMA-CLI native code generator (Just-in-Time and Ahead-

       mono [options] file [arguments...]

       mono-sgen [options] file [arguments...]

       mono is a runtime implementation of the	ECMA  Common  Language	Infra‐
       structure.  This can be used to run ECMA and .NET applications.

       The runtime contains a native code generator that transforms the Common
       Intermediate Language into native code.

       The code generator can operate in two modes: just in  time  compilation
       (JIT)  or  ahead	 of time compilation (AOT).  Since code can be dynami‐
       cally loaded, the runtime environment and the JIT are  always  present,
       even if code is compiled ahead of time.

       The  runtime  loads  the specified file and optionally passes the argu‐
       ments to it.  The file is an ECMA assembly.  They typically have a .exe
       or .dll extension.

       The  runtime  provides  a  number  of configuration options for running
       applications, for developing and debugging, and for testing and	debug‐
       ging the runtime itself.

       The  mono  command  uses the Boehm conservative garbage collector while
       the mono-sgen command uses a moving and generational garbage collector.

       On Unix-based systems, Mono provides a mechanism to  emulate  the  Win‐
       dows-style file access, this includes providing a case insensitive view
       of the file system, directory separator	mapping	 (from	\  to  /)  and
       stripping the drive letters.

       This  functionality  is	enabled	 by setting the MONO_IOMAP environment
       variable to one of all, drive and case.

       See the description for MONO_IOMAP in the environment variables section
       for more details.

       The following options are available:

       --aot, --aot[=options]
	      This  option is used to precompile the CIL code in the specified
	      assembly to native code.	The generated code is stored in a file
	      with  the extension .so.	This file will be automatically picked
	      up by the runtime when the assembly is executed.	 Ahead-of-Time
	      compilation is most useful if you use it in combination with the
	      -O=all,-shared flag which enables all of	the  optimizations  in
	      the code generator to be performed.  Some of those optimizations
	      are not practical for Just-in-Time compilation since they	 might
	      be  very	time  consuming.  Unlike the .NET Framework, Ahead-of-
	      Time compilation will not generate domain independent  code:  it
	      generates	 the  same  code  that the Just-in-Time compiler would
	      produce.	 Since most applications use a single domain, this  is
	      fine.    If  you	want to optimize the generated code for use in
	      multi-domain applications, consider using	 the  -O=shared	 flag.
	      This  pre-compiles  the  methods,	 but  the original assembly is
	      still required to execute as this one contains the metadata  and
	      exception	 information  which  is not available on the generated
	      file.  When precompiling code, you might want  to	 compile  with
	      all optimizations (-O=all).  Pre-compiled code is position inde‐
	      pendent code.  Pre compilation is just  a	 mechanism  to	reduce
	      startup  time,  increase	code sharing across multiple mono pro‐
	      cesses and avoid just-in-time compilation program startup costs.
	      The  original assembly must still be present, as the metadata is
	      contained there.	AOT code typically can not be moved  from  one
	      computer	 to   another  (CPU-specific  optimizations  that  are
	      detected at runtime) so you should not try to move the  pre-gen‐
	      erated  assemblies  or  package the pre-generated assemblies for
	      deployment.  A few options are available as a parameter  to  the
	      --aot  command  line option.   The options are separated by com‐
	      mas, and more than one can be specified:

		     The AOT compiler will emit a (ELF only) library  initial‐
		     izer  to  automatically  register the aot compiled module
		     with the runtime.	This is only useful in static mode

		     Instructs	the  AOT  compiler  to	output	assembly  code
		     instead of an object file.

		     If	 specified, forces the generated AOT files to be bound
		     to the runtime version of the compiling Mono.   This will
		     prevent  the AOT files from being consumed by a different
		     Mono runtime.  full This  is  currently  an  experimental
		     feature  as  it  is not complete.	This instructs Mono to
		     precompile code that has historically  not	 been  precom‐
		     piled with AOT.

		     When  this	 option	 is  specified,	 P/Invoke  methods are
		     invoked directly instead of going through	the  operating
		     system symbol lookup operation.

		     Same for the llvm tools 'opt' and 'llc'.

		     Use  the  GNU  style  target triple <TRIPLE> to determine
		     some      code	  generation	   options,	  i.e.
		     --mtriple=armv7-linux-gnueabi  will  generate  code  that
		     targets ARMv7. This is currently only  supported  by  the
		     ARM  backend.  In	LLVM mode, this triple is passed on to
		     the LLVM llc compiler.

		     When compiling in full aot mode, the IMT trampolines must
		     be	 precreated  in the AOT image.	You can add additional
		     method trampolines with this argument.  Defaults to 128.

		     Instructs the AOT compiler to not	output	any  debugging

		     Instructs the AOT compiler to emit DWARF debugging infor‐
		     mation. When used together with the nodebug option,  only
		     DWARF  debugging  information  is	emitted,  but  not the
		     information that can be used at runtime.

		     When compiling in full  aot  mode,	 the  generic  sharing
		     trampolines must be precreated in the AOT image.  You can
		     add additional method  trampolines	 with  this  argument.
		     Defaults to 1024.

		     When  compiling  in full aot mode, the method trampolines
		     must be precreated in the AOT image.  You can  add	 addi‐
		     tional  method  trampolines with this argument.  Defaults
		     to 1024.

		     Instructs the AOT compiler to  save  the  output  to  the
		     specified file.

		     If	 the AOT compiler cannot compile a method for any rea‐
		     son, enabling this flag will output the  skipped  methods
		     to the console.

		     Override  the  value of a static readonly field. Usually,
		     during JIT compilation, the  static  constructor  is  ran
		     eagerly, so the value of a static readonly field is known
		     at compilation time and the compiler can do a  number  of
		     optimizations  based  on  it.  During  AOT,  instead, the
		     static constructor can't be ran, so this  option  can  be
		     used to set the value of such a field and enable the same
		     set of optimizations.  Type can be any of i1, i2, i4  for
		     integers  of  the respective sizes (in bytes).  Note that
		     signed/unsigned numbers do	 not  matter  here,  just  the
		     storage  size.   This  option  can	 be specified multiple
		     times and it doesn't prevent the static  constructor  for
		     the  type	defining  the  field to execute with the usual
		     rules at runtime (hence possibly  computing  a  different
		     value for the field).

		     Instructs the AOT compiler to keep temporary files.

		     This  instructs  the  compiler to generate sequence point
		     checks that allow Mono's soft debugger to debug  applica‐
		     tions  even  on  systems  where it is not possible to set
		     breakpoints or to single step (certain hardware  configu‐
		     rations like the cell phones and video gaming consoles).

	      static Create  an	 ELF  object file (.o) or .s file which can be
		     statically linked into an executable when	embedding  the
		     mono  runtime.  When this option is used, the object file
		     needs to be registered with the  embedded	runtime	 using
		     the  mono_aot_register_module function which takes as its
		     argument the mono_aot_module_<ASSEMBLY NAME>_info	global
		     symbol from the object file:

		     extern void *mono_aot_module_hello_info;

		     mono_aot_register_module (mono_aot_module_hello_info);

	      stats  Print various stats collected during AOT compilation.

		     This  is  an  experimental option for the AOT compiler to
		     use multiple threads when compiling the methods.

		     Prepends <PREFIX> to the name of tools  ran  by  the  AOT
		     compiler, i.e. 'as'/'ld'. For example, --tool=prefix=arm-
		     linux-gnueabi- will make the AOT compiler run

		     Instructs the AOT compiler to emit debug symbol  informa‐

	      For   more   information	 about	 AOT,	see:  http://www.mono-

	      Currently the only option supported by this command  line	 argu‐
	      ment is disable which disables the attach functionality.

       --config filename
	      Load  the	 specified  configuration  file instead of the default
	      one(s).  The default files are /etc/mono/config and ~/.mono/con‐
	      fig  or  the file specified in the MONO_CONFIG environment vari‐
	      able, if set.  See the mono-config(5) man page  for  details  on
	      the format of this file.

	      This  instructs  the  Mono  runtime  to  start a debugging agent
	      inside the Mono runtime and connect it to a client  user	inter‐
	      face  will  control  the Mono process.  This option is typically
	      used by IDEs, like the MonoDevelop IDE.

       The configuration is specified using  one  of  more  of	the  following

		     Use  this	option	to  specify  the IP address where your
		     debugger client is listening to.

		     Specifies the diagnostics log level for

		     Used to specify the file where the log will be stored, it
		     defaults to standard output.

		     Defaults  to  no,	with  the  default  option  Mono  will
		     actively connect to the  host/port	 configured  with  the
		     address  option.	If you set it to 'y', it instructs the
		     Mono runtime to start debugging  in  server  mode,	 where
		     Mono actively waits for the debugger front end to connect
		     to the Mono process.  Mono will print out to  stdout  the
		     IP address and port where it is listening.

		     If	 set  to yes, Mono will call setpgid(0, 0) on startup,
		     if that function is available on the system. This is use‐
		     ful for ensuring that signals delivered to a process that
		     is executing the  debuggee	 are  not  propagated  to  the
		     debuggee, e.g. when Ctrl-C sends SIGINT to the sdb tool.

		     Defaults  to  yes, with the default option Mono will sus‐
		     pend the vm on startup until it connects successfully  to
		     a	debugger front end.  If you set it to 'n', in conjunc‐
		     tion with server=y, it instructs the Mono runtime to  run
		     as normal, while caching metadata to send to the debugger
		     front end on connection..

		     This is used to specify the transport that	 the  debugger
		     will  use to communicate.	 It must be specified and cur‐
		     rently requires this to be 'dt_socket'.

	      Configures the virtual machine to be better suited  for  desktop
	      applications.   Currently	 this  sets  the  GC  system  to avoid
	      expanding the heap as much as possible at the expense of slowing
	      down garbage collection a bit.

	      This  is an experimental flag that instructs the Mono runtime to
	      not generate any code at runtime and depend exclusively  on  the
	      code  generated from using mono --aot=full previously.   This is
	      useful for platforms that do not permit dynamic code generation.
	      Notice  that  this  feature will abort execution at runtime if a
	      codepath in your program, or Mono's class libraries attempts  to
	      generate	code  dynamically.   You  should  test	your  software
	      upfront and make sure that you do not use any dynamic features.

       --gc=boehm, --gc=sgen
	      Selects the Garbage Collector engine for Mono to use,  Boehm  or
	      SGen.  Currently this merely ensures that you are running either
	      the mono or mono-sgen commands.	 This flag can be set  in  the
	      MONO_ENV_OPTIONS environment variable to force all of your child
	      processes to use one particular kind of GC with  the  Mono  run‐

       --help, -h
	      Displays usage instructions.

       --llvm If  the  Mono  runtime  has been compiled with LLVM support (not
	      available in all configurations), Mono will use the  LLVM	 opti‐
	      mization	and code generation engine to JIT or AOT compile.  For
	      more information, consult:

	      When using a Mono that has been compiled with LLVM  support,  it
	      forces  Mono  to fallback to its JIT engine and not use the LLVM

       --optimize=MODE, -O=MODE
	      MODE is a comma separated	 list  of  optimizations.   They  also
	      allow  optimizations to be turned off by prefixing the optimiza‐
	      tion name with a minus sign.  In general, Mono has been tuned to
	      use  the	default	 set  of flags, before using these flags for a
	      deployment setting, you might want to actually measure the bene‐
	      fits  of	using  them.   The  following optimizations are imple‐
			   all	      Turn on all optimizations
			   peephole   Peephole postpass
			   branch     Branch optimizations
			   inline     Inline method calls
			   cfold      Constant folding
			   consprop   Constant propagation
			   copyprop   Copy propagation
			   deadce     Dead code elimination
			   linears    Linear scan global reg allocation
			   cmov	      Conditional moves [arch-dependency]
			   shared     Emit per-domain code
			   sched      Instruction scheduling
			   intrins    Intrinsic method implementations
			   tailc      Tail recursion and tail calls
			   loop	      Loop related optimizations
			   fcmov      Fast x86 FP compares [arch-dependency]
			   leaf	      Leaf procedures optimizations
			   aot	      Usage of Ahead Of Time compiled code
			   precomp    Precompile all methods before executing Main
			   abcrem     Array bound checks removal
			   ssapre     SSA based Partial Redundancy Elimination
			   sse2	      SSE2 instructions on x86 [arch-dependency]
			   gshared    Enable generic code sharing.
	      For example, to enable all the optimization but dead code elimi‐
	      nation and inlining, you can use:
	      The  flags that are flagged with [arch-dependency] indicate that
	      the given option if used in combination with Ahead of Time  com‐
	      pilation	(--aot flag) would produce pre-compiled code that will
	      depend on the current CPU and  might  not	 be  safely  moved  to
	      another computer.

	      Mono  supports  different	 runtime  versions.  The  version used
	      depends on the program that is being run or on its configuration
	      file  (named  program.exe.config).  This	option	can be used to
	      override such autodetection, by forcing a different runtime ver‐
	      sion  to be used. Note that this should only be used to select a
	      later compatible runtime version than the one  the  program  was
	      compiled	against.  A typical usage is for running a 1.1 program
	      on a 2.0 version:
		       mono --runtime=v2.0.50727 program.exe

       --security, --security=mode
	      Activate the security manager, a currently experimental  feature
	      in  Mono	and it is OFF by default. The new code verifier can be
	      enabled with this option as well.

	      Using security without parameters is equivalent  as  calling  it
	      with the "cas" parameter.

	      The following modes are supported:

	      cas    This   allows   mono   to	support	 declarative  security
		     attributes, e.g. execution of Code Access Security	 (CAS)
		     or non-CAS demands.

		     Enables  the core-clr security system, typically used for
		     Moonlight/Silverlight applications.  It provides  a  much
		     simpler  security	system	than CAS, see http://www.mono- for more details and links  to  the
		     descriptions of this new system.

		     Enables  the new verifier and performs basic verification
		     for  code	validity.   In	this  mode,  unsafe  code  and
		     P/Invoke  are allowed. This mode provides a better safety
		     guarantee but it is still possible for  managed  code  to
		     crash Mono.

		     Enables  the  new verifier and performs full verification
		     of the code being executed.  It  only  allows  verifiable
		     code  to  be  executed.   Unsafe  code is not allowed but
		     P/Invoke is.  This mode should not allow managed code  to
		     crash  mono.   The	 verification is not as strict as ECMA
		     335 standard in order to stay compatible with the MS run‐

	      The  security system acts on user code: code contained in mscor‐
	      lib or the global assembly cache is always trusted.

	      Configures the virtual machine to be better  suited  for	server
	      operations  (currently,  allows a heavier threadpool initializa‐

	      Verifies mscorlib and assemblies in the  global  assembly	 cache
	      for valid IL, and all user code for IL verifiability.

	      This  is	different  from	 --security's verifiable or validil in
	      that these options only check user code and  skip	 mscorlib  and
	      assemblies located on the global assembly cache.

       -V, --version
	      Prints  JIT  version  information (system configuration, release
	      number and branch names if available).

       The following options are used to help when developing a JITed applica‐

       --debug, --debug=OPTIONS
	      Turns  on the debugging mode in the runtime.  If an assembly was
	      compiled with debugging information, it will produce line number
	      information for stack traces.

	      The  optional  OPTIONS  argument	is  a  comma separated list of
	      debugging options.  These options	 are  turned  off  by  default
	      since they generate much larger and slower code at runtime.

	      The following options are supported:

	      casts  Produces  a detailed error when throwing a InvalidCastEx‐
		     ception.	This option needs to be enabled as this gener‐
		     ates more verbose code at execution time.

		     Disable  some  JIT	 optimizations	which are usually only
		     disabled when running inside the debugger.	 This  can  be
		     helpful if you want to attach to the running process with

	      gdb    Generate and register  debugging  information  with  gdb.
		     This  is  only supported on some platforms, and only when
		     using gdb 7.0 or later.

	      Turns on profiling.  For more information about profiling appli‐
	      cations and code coverage see the sections "PROFILING" and "CODE
	      COVERAGE" below.

       This option can be used multiple times, each time will load an
	      additional profiler.   This allows  developers  to  use  modules
	      that extend the JIT through the Mono profiling interface.

	      Shows  method names as they are invoked.	By default all methods
	      are traced.  The trace can be customized to include  or  exclude
	      methods,	classes	 or assemblies.	 A trace expression is a comma
	      separated list of targets, each target can be  prefixed  with  a
	      minus  sign  to  turn  off a particular target.  The words `pro‐
	      gram', `all' and `disabled'  have	 special  meaning.   `program'
	      refers  to  the main program being executed, and `all' means all
	      the method calls.	 The `disabled' option is  used	 to  start  up
	      with  tracing  disabled.	 It can be enabled at a later point in
	      time in the program by sending the SIGUSR2 signal	 to  the  run‐
	      time.   Assemblies  are specified by their name, for example, to
	      trace all calls in the System assembly, use:

		   mono --trace=System app.exe

	      Classes are specified with the T: prefix.	 For example, to trace
	      all calls to the System.String class, use:

		   mono --trace=T:System.String app.exe

	      And  individual  methods	are referenced with the M: prefix, and
	      the standard method notation:

		   mono --trace=M:System.Console:WriteLine app.exe

	      Exceptions can also be traced, it will cause a stack trace to be
	      printed every time an exception of the specified type is thrown.
	      The exception type can be specified with or without  the	names‐
	      pace,  and  to  trace  all exceptions, specify 'all' as the type

		   mono --trace=E:System.Exception app.exe

	      As previously noted, various rules can be specified at once:

		   mono --trace=T:System.String,T:System.Random app.exe

	      You can exclude pieces, the next example traces  calls  to  Sys‐
	      tem.String except for the System.String:Concat method.

		   mono --trace=T:System.String,-M:System.String:Concat

	      You can trace managed to unmanaged transitions using the wrapper

		   mono --trace=wrapper app.exe

	      Finally, namespaces can be specified using the N: prefix:

		   mono --trace=N:System.Xml

	      Don't align stack frames on the x86 architecture.	  By  default,
	      Mono  aligns  stack  frames  to  16  bytes on x86, so that local
	      floating point and SIMD variables can be properly aligned.  This
	      option  turns off the alignment, which usually saves one intruc‐
	      tion per call, but might result in significantly lower  floating
	      point and SIMD performance.

	      Generate a JIT method map in a /tmp/ file. This file
	      is then used, for example, by the perf tool included  in	recent
	      Linux kernels.  Each line in the file has:

		   HEXADDR HEXSIZE methodname

	      Currently this option is only supported on Linux.

       The  maintainer	options	 are only used by those developing the runtime
       itself, and not typically of interest to runtime users or developers.

       --break method
	      Inserts a breakpoint before the method whose  name  is  `method'
	      (namespace.class:methodname).   Use  `Main'  as  method  name to
	      insert a breakpoint on the application's main method.   You  can
	      use   it	 also	with  generics,	 for  example  "System.Collec‐

	      Inserts a breakpoint on exceptions.  This allows	you  to	 debug
	      your  application	 with  a  native debugger when an exception is

       --compile name
	      This compiles a method (, this is used
	      for testing the compiler performance or to examine the output of
	      the code generator.

	      Compiles all the methods in an assembly.	This is used  to  test
	      the  compiler  performance  or to examine the output of the code

       --graph=TYPE METHOD
	      This generates a postscript file with a graph with  the  details
	      about  the  specified  method (  This
	      requires `dot' and ghostview to be installed (it expects	Ghost‐
	      view to be called "gv").	The following graphs are available:
			cfg	   Control Flow Graph (CFG)
			dtree	   Dominator Tree
			code	   CFG showing code
			ssa	   CFG showing code after SSA translation
			optcode	   CFG showing code after IR optimizations
	      Some  graphs will only be available if certain optimizations are
	      turned on.

	      Instruct the runtime on the number  of  times  that  the	method
	      specified	 by  --compile	(or all the methods if --compileall is
	      used) to be compiled.  This is used for testing the code genera‐
	      tor performance.

	      Displays	information  about the work done by the runtime during
	      the execution of an application.

	      Perform maintenance of the process  shared  data.	  semdel  will
	      delete  the  global semaphore.  hps will list the currently used

       -v, --verbose
	      Increases the verbosity level, each time it is listed, increases
	      the  verbosity level to include more information (including, for
	      example, a disassembly of the native code produced, code	selec‐
	      tor info etc.).

       The  Mono  runtime  allows  external  processes	to attach to a running
       process and load assemblies into the running program.	To  attach  to
       the  process,  a special protocol is implemented in the Mono.Management

       With this support it is possible to load assemblies that have an	 entry
       point  (they  are  created  with	 -target:exe  or -target:winexe) to be
       loaded and executed in the Mono process.

       The code is loaded into the root domain, and it starts execution on the
       special	runtime	 attach	 thread.    The attached program should create
       its own threads and return after invocation.

       This support allows for example debugging applications  by  having  the
       csharp shell attach to running processes.

       The  mono runtime includes a profiler that can be used to explore vari‐
       ous performance related problems in your application.  The profiler  is
       activated  by  passing  the --profile command line argument to the Mono
       runtime, the format is:


       Mono has a built-in profiler called 'default' (and is also the  default
       if no arguments are specified), but developers can write custom profil‐
       ers, see the section "CUSTOM PROFILERS" for more details.

       If a profiler is not specified, the default profiler is used.  The pro‐
       filer_args  is  a  profiler-specific string of options for the profiler
       itself.	The default profiler accepts the following options 'alloc'  to
       profile	memory	consumption  by the application; 'time' to profile the
       time spent on each routine; 'jit' to collect time  spent	 JIT-compiling
       methods	and  'stat'  to	 perform  sample statistical profiling.	 If no
       options are provided the default is 'alloc,time,jit'.

       By default the profile data is printed to stdout: to change  this,  use
       the  'file=filename'  option to output the data to filename.  For exam‐

	    mono --profile program.exe

       That will run the program with the default profiler and	will  do  time
       and allocation profiling.

	    mono --profile=default:stat,alloc,file=prof.out program.exe

       Will  do	 sample statistical profiling and allocation profiling on pro‐
       gram.exe. The profile data is put in prof.out.  Note that the statisti‐
       cal  profiler  has a very low overhead and should be the preferred pro‐
       filer to use (for better output use the full path to  the  mono	binary
       when  running  and  make	 sure you have installed the addr2line utility
       that comes from the binutils package).

       This is the most advanced profiler.

       The Mono log profiler can be used to collect a lot of information about
       a  program  running  in	the Mono runtime.  This data can be used (both
       while the process is running and later) to do analyses of  the  program
       behaviour,  determine  resource	usage, performance issues or even look
       for particular execution patterns.

       This is accomplished by logging the events provided by the Mono runtime
       through the profiling interface and periodically writing them to a file
       which can be later inspected with the mprof-report(1) tool.

       More information about how to use the log profiler is available on  the
       mprof-report(1) page.

       Mono  provides a mechanism for loading other profiling modules which in
       the form of shared libraries.  These profiling modules can hook	up  to
       various	parts of the Mono runtime to gather information about the code
       being executed.

       To use a third party profiler you must pass the name of the profiler to
       Mono, like this:

	    mono --profile=custom program.exe

       In  the	above sample Mono will load the user defined profiler from the
       shared library `'.  This profiler module must be
       on your dynamic linker library path.

       A list of other third party profilers is available from Mono's web site

       Custom profiles are written as shared libraries.	  The  shared  library
       must be called `' where `NAME' is the name of your

       For a sample of how to write your own custom profiler look in the  Mono
       source tree for in the samples/profiler.c.

       Mono  ships  with  a code coverage module.  This module is activated by
       using  the  Mono	 --profile=cov	option.	   The	 format	  is:	--pro‐
       file=cov[:assembly-name[/namespace]] test-suite.exe

       By default code coverage will default to all the assemblies loaded, you
       can limit this by specifying the assembly name, for example to  perform
       code coverage in the routines of your program use, for example the fol‐
       lowing command line limits the code coverage to routines in the	"demo"

	    mono --profile=cov:demo demo.exe

       Notice that the assembly-name does not include the extension.

       You  can	 further  restrict  the	 code  coverage output by specifying a

	    mono --profile=cov:demo/My.Utilities demo.exe

       Which will only perform code coverage in the given assembly and	names‐

       Typical output looks like this:

	    Not covered: Class:.ctor ()
	    Not covered: Class:A ()
	    Not covered: Driver:.ctor ()
	    Not covered: Driver:method ()
	    Partial coverage: Driver:Main ()
		 offset 0x000a

       The offsets displayed are IL offsets.

       A  more	powerful  coverage  tool is available in the module `monocov'.
       See the monocov(1) man page for details.

       To debug managed applications, you can use the mdb command,  a  command
       line debugger.

       It  is  possible	 to  obtain a stack trace of all the active threads in
       Mono by sending the QUIT signal to Mono, you can do this from the  com‐
       mand line, like this:

	    kill -QUIT pid

       Where  pid  is  the Process ID of the Mono process you want to examine.
       The process will continue running afterwards,  but  its	state  is  not

       Important:  this	 is a last-resort mechanism for debugging applications
       and should not be used to monitor or probe  a  production  application.
       The  integrity  of the runtime after sending this signal is not guaran‐
       teed and the application might crash or terminate at  any  given	 point

       The  --debug=casts  option can be used to get more detailed information
       for Invalid Cast operations, it	will  provide  information  about  the
       types involved.

       You  can use the MONO_LOG_LEVEL and MONO_LOG_MASK environment variables
       to get verbose debugging output about the execution of your application
       within Mono.

       The  MONO_LOG_LEVEL  environment	 variable if set, the logging level is
       changed to the set value.  Possible  values  are	 "error",  "critical",
       "warning",  "message",  "info",	"debug". The default value is "error".
       Messages with a logging level greater then or equal to  the  log	 level
       will be printed to stdout/stderr.

       Use "info" to track the dynamic loading of assemblies.

       Use  the	 MONO_LOG_MASK environment variable to limit the extent of the
       messages you get: If set, the log mask is changed  to  the  set	value.
       Possible	 values	 are  "asm"  (assembly	loader), "type", "dll" (native
       library loader), "gc" (garbage collector), "cfg" (config file  loader),
       "aot"  (precompiler),  "security"  (e.g. Moonlight CoreCLR support) and
       "all".  The default value is "all". Changing the mask value allows  you
       to  display only messages for a certain component. You can use multiple
       masks by comma separating them. For example to see config file messages
       and assembly loader messages set you mask to "asm,cfg".

       The following is a common use to track down problems with P/Invoke:

	    $ MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" mono glue.exe

       Mono's  XML serialization engine by default will use a reflection-based
       approach to serialize which might be  slow  for	continuous  processing
       (web  service  applications).   The serialization engine will determine
       when a class must use a hand-tuned serializer based on a few parameters
       and if needed it will produce a customized C# serializer for your types
       at runtime.  This customized serializer then  gets  dynamically	loaded
       into your application.

       You  can control this with the MONO_XMLSERIALIZER_THS environment vari‐

       The possible values are `no' to disable the  use	 of  a	C#  customized
       serializer, or an integer that is the minimum number of uses before the
       runtime will produce a custom serializer (0 will produce a custom seri‐
       alizer  on  the	first access, 50 will produce a serializer on the 50th
       use). Mono will fallback to an interpreted serializer if the serializer
       generation  somehow fails. This behavior can be disabled by setting the
       option `nofallback' (for example: MONO_XMLSERIALIZER_THS=0,nofallback).

	      Turns off the garbage collection in Mono.	 This should  be  only
	      used for debugging purposes

	      When Mono is compiled with LLVM support, this instructs the run‐
	      time to stop using LLVM after the specified  number  of  methods
	      are  JITed.   This is a tool used in diagnostics to help isolate
	      problems	in  the	 code  generation   backend.	 For   example
	      LLVM_COUNT=10  would  only compile 10 methods with LLVM and then
	      switch to the Mono JIT engine.  LLVM_COUNT=0 would  disable  the
	      LLVM engine altogether.

	      If  set,	this variable will instruct Mono to ahead-of-time com‐
	      pile new assemblies on demand and store the result into a	 cache
	      in ~/.mono/aot-cache.

	      Mono  contains  a feature which allows modifying settings in the
	      .config files shipped with Mono by using config section mappers.
	      The  mappers  and	 the  mapping  rules  are defined in the $pre‐
	      fix/etc/mono/2.0/ file and, optionally, in the  set‐	 file found in the top-level directory of your ASP.NET
	      application.  Both files are read by System.Web  on  application
	      startup,	if they are found at the above locations. If you don't
	      want the mapping to be performed you can set  this  variable  in
	      your  environment	 before starting the application and no action
	      will be taken.

	      Mono has a cache of ConfigSection objects for speeding  up  Web‐
	      ConfigurationManager queries. Its default size is 100 items, and
	      when more items are needed, cache evictions start happening.  If
	      evictions	 are  too frequent this could impose unnecessary over‐
	      head, which could be avoided by using this environment  variable
	      to  set  up a higher cache size (or to lower memory requirements
	      by decreasing it).

	      If set, causes Mono.Cairo to collect stack traces	 when  objects
	      are allocated, so that the finalization/Dispose warnings include
	      information about the instance's origin.

	      If set, this variable overrides the default system configuration
	      directory	 ($PREFIX/etc).	 It's  used  to	 locate machine.config

	      Sets the style of COM interop.  If the value of this variable is
	      "MS"   Mono  will	 use  string  marhsalling  routines  from  the
	      liboleaut32 for the BSTR type library, any other values will use
	      the mono-builtin BSTR string marshalling.

	      If  set,	this variable overrides the default runtime configura‐
	      tion file ($PREFIX/etc/mono/config). The --config	 command  line
	      options overrides the environment variable.

	      Override	the  automatic cpu detection mechanism. Currently used
	      only on arm.  The format of the value is as follows:

		   "armvV [thumb]"

	      where V is the architecture number 4, 5, 6, 7  and  the  options
	      can be currently be "thunb". Example:

		   MONO_CPU_ARCH="armv4 thumb" mono ...

	      If  set, tells mono NOT to attempt using native asynchronous I/O
	      services. In that case, a default select/poll implementation  is
	      used. Currently only epoll() is supported.

	      If  this	environment variable is `yes', the runtime uses unman‐
	      aged collation (which actually means no culture-sensitive colla‐
	      tion).  It  internally  disables managed collation functionality
	      invoked  via  the	 members  of  System.Globalization.CompareInfo
	      class. Collation is enabled by default.

	      Unix  only:  If  set,  disables the shared memory files used for
	      cross-process handles: process have only private handles.	  This
	      means that process and thread handles are not available to other
	      processes, and named mutexes, named events and named  semaphores
	      are  not visible between processes.  This is can also be enabled
	      by default by passing the "--disable-shared-handles"  option  to
	      configure.  This is the default from mono 2.8 onwards.

	      Unix  only:  If set, disable usage of shared memory for exposing
	      performance counters. This means it will not be possible to both
	      externally read performance counters from this processes or read
	      those of external processes.

	      When set, enables the  use  of  a	 fully	managed	 DNS  resolver
	      instead  of  the	regular libc functions. This resolver performs
	      much better when multiple queries are run in parallel.

	      Note that /etc/nsswitch.conf will be ignored.

	      For platforms that do not otherwise have a way of obtaining ran‐
	      dom bytes this can be set to the name of a file system socket on
	      which an egd or prngd daemon is listening.

	      Unix only: Enable support	 for  cross-process  handles.	Cross-
	      process  handles are used to expose process handles, thread han‐
	      dles, named mutexes, named events and  named  semaphores	across
	      Unix processes.

	      This  environment variable allows you to pass command line argu‐
	      ments to a Mono process through the environment.	 This is  use‐
	      ful  for example to force all of your Mono processes to use LLVM
	      or SGEN without having to modify any launch scripts.

	      Used to pass extra options to the debugger agent in the runtime,
	      as they were passed using --debugger-agent=.

	      Sets  the type of event log provider to use (for System.Diagnos‐
	      tics.EventLog).  Possible values are:

		     Persists event logs and entries to the local file system.
		     The  directory  in which to persist the event logs, event
		     sources and entries can  be  specified  as	 part  of  the
		     value.  If the path is not explicitly set, it defaults to
		     "/var/lib/mono/eventlog" on unix  and  "%APPDATA%no\vent‐
		     log" on Windows.

	      win32  Uses  the	native win32 API to write events and registers
		     event logs and event sources in the registry.    This  is
		     only  available  on Windows.  On Unix, the directory per‐
		     mission for individual event log and event source	direc‐
		     tories  is	 set to 777 (with +t bit) allowing everyone to
		     read and write event  log	entries	 while	only  allowing
		     entries to be deleted by the user(s) that created them.

	      null   Silently discards any events.

	      The  default  is	"null" on Unix (and versions of Windows before
	      NT), and "win32" on Windows NT (and higher).

	      If set, contains a colon-separated list of text encodings to try
	      when  turning externally-generated text (e.g. command-line argu‐
	      ments or filenames) into Unicode.	 The encoding names come  from
	      the   list   provided   by   iconv,   and	  the	special	  case
	      "default_locale" which refers to the  current  locale's  default

	      When  reading  externally-generated  text strings UTF-8 is tried
	      first, and then this list is tried in order with the first  suc‐
	      cessful  conversion  ending  the	search.	 When writing external
	      text (e.g. new filenames or  arguments  to  new  processes)  the
	      first  item  in  this  list is used, or UTF-8 if the environment
	      variable is not set.

	      The problem with using MONO_EXTERNAL_ENCODINGS to	 process  your
	      files  is that it results in a problem: although its possible to
	      get the right file name it is not necessarily possible  to  open
	      the  file.   In  general	if you have problems with encodings in
	      your filenames you should use the "convmv" program.

	      When using Mono with the SGen garbage  collector	this  variable
	      controls	several	 parameters  of the collector.	The variable's
	      value is a comma separated list of words.

		     Sets the size of the nursery.  The size is	 specified  in
		     bytes  and must be a power of two.	 The suffixes `k', `m'
		     and `g' can be used to specify  kilo-,  mega-  and	 giga‐
		     bytes, respectively.  The nursery is the first generation
		     (of two).	A larger nursery will  usually	speed  up  the
		     program  but will obviously use more memory.  The default
		     nursery size 4 MB.

		     Specifies which major  collector  to  use.	  Options  are
		     `marksweep'  for  the  Mark&Sweep	collector, `marksweep-
		     conc' for concurrent Mark&Sweep, `marksweep-par' for par‐
		     allel Mark&Sweep, `marksweep-fixed' for Mark&Sweep with a
		     fixed  heap,  and	`marksweep-fixed-par'	for   parallel
		     Mark&Sweep with a fixed heap. The Mark&Sweep collector is
		     the default.

		     Sets the size of the major heap (not including the	 large
		     object  space)  for  the  fixed-heap Mark&Sweep collector
		     (i.e. `marksweep-fixed' and `marksweep-fixed-par').   The
		     size is in bytes, with optional suffixes `k', `m' and `g'
		     to specify kilo-, mega- and gigabytes, respectively.  The
		     default is 512 megabytes.

		     Once  the	heap  size  gets larger than this size, ignore
		     what the default major collection trigger metric says and
		     only  allow  four	nursery	 size's	 of  major heap growth
		     between major collections.

		     Sets the evacuation threshold in percent.	This option is
		     only  available  on the Mark&Sweep major collectors.  The
		     value must be an integer in the  range  0	to  100.   The
		     default  is  66.	If  the	 sweep phase of the collection
		     finds that the occupancy of a specific heap block type is
		     less  than	 this percentage, it will do a copying collec‐
		     tion for that block type in the  next  major  collection,
		     thereby  restoring	 occupancy to close to 100 percent.  A
		     value of 0 turns evacuation off.

		     Enables or disables lazy sweep for the Mark&Sweep collec‐
		     tor.   If enabled, the sweep phase of the garbage collec‐
		     tion is done piecemeal whenever the  need	arises,	 typi‐
		     cally  during  nursery  collections.   Lazy  sweeping  is
		     enabled by default.

		     Specifies how  application	 threads  should  be  scanned.
		     Options are `precise` and `conservative`. Precise marking
		     allow the collector to know what values on stack are ref‐
		     erences  and  what are not.  Conservative marking threats
		     all values	 as  potentially  references  and  leave  them
		     untouched.	 Precise  marking reduces floating garbage and
		     can speed up nursery collection and allocation  rate,  it
		     has  the downside of requiring a significant extra memory
		     per compiled method.  The	right  option,	unfortunately,
		     requires experimentation.

		     Specifies	the target save ratio for the major collector.
		     The collector lets a given amount of memory  to  be  pro‐
		     moted from the nursery due to minor collections before it
		     triggers a major collection. This amount is based on  how
		     much  memory  it  expects to free. It is represented as a
		     ratio of the size of the heap after a  major  collection.
		     Valid values are between 0.1 and 2.0. The default is 0.5.
		     Smaller values will keep the major heap size smaller  but
		     will  trigger  more  major	 collections. Likewise, bigger
		     values will use more memory and result in	less  frequent
		     major  collections.   This	 option is EXPERIMENTAL, so it
		     might disappear in later versions of mono.

		     Specifies the default allocation allowance when the  cal‐
		     culated  size  is	too small. The allocation allowance is
		     how much memory the  collector  let  be  promoted	before
		     triggered a major collection.  It is a ratio of the nurs‐
		     ery size.	Valid values are between  1.0  and  10.0.  The
		     default is 4.0.  Smaller values lead to smaller heaps and
		     more frequent major collections.  Likewise, bigger values
		     will  allow  the  heap to grow faster but use more memory
		     when it reaches a stable size.  This option is EXPERIMEN‐
		     TAL, so it might disappear in later versions of mono.

		     Specifies which minor collector to use. Options are 'sim‐
		     ple' which promotes all objects from the nursery directly
		     to	 the old generation and 'split' which lets object stay
		     longer on the nursery before promoting.

		     Specifies the ratio of memory from the nursery to be  use
		     by	 the alloc space.  This only can only be used with the
		     split minor collector.  Valid values are integers between
		     1 and 100. Default is 60.

		     Specifies the required age of an object must reach inside
		     the nursery before been promoted to the  old  generation.
		     This  only	 can only be used with the split minor collec‐
		     tor.  Valid values are integers between 1 and 14. Default
		     is 2.

		     Enables  or  disables  cementing.	 This can dramatically
		     shorten nursery collection times on some benchmarks where
		     pinned objects are referred to from the major heap.

	      When using Mono with the SGen garbage collector this environment
	      variable can be used to turn on various  debugging  features  of
	      the  collector.  The value of this variable is a comma separated
	      list of words.  Do not use these options in production.

	      number Sets the debug level to the specified number.

		     After each major collection prints memory consumption for
		     before and after the collection and the allowance for the
		     minor collector, i.e. how much the	 heap  is  allowed  to
		     grow from minor collections before the next major collec‐
		     tion is triggered.

		     Gathers statistics	 on  the  classes  whose  objects  are
		     pinned in the nursery and for which global remset entries
		     are added.	 Prints those statistics when shutting down.


		     This performs a consistency check	on  minor  collections
		     and  also	clears the nursery at collection time, instead
		     of the default, when buffers are allocated (clear-at-gc).
		     The  consistency check ensures that there are no major to
		     minor references that are not on the remembered sets.

		     Checks that the mod-union cardtable is consistent	before
		     each  finishing  major  collection	 pause.	 This check is
		     only applicable to concurrent major collectors.

		     Checks that mark bits in the major heap are consistent at
		     the  end  of each major collection.  Consistent mark bits
		     mean that if an object is marked, all objects that it had
		     references to must also be marked.

		     After nursery collections, and before starting concurrent
		     collections,  check  whether  all	nursery	 objects   are
		     pinned, or not pinned - depending on context.  Does noth‐
		     ing when the split nursery collector is used.

		     Performs a check to make sure that no references are left
		     to an unloaded AppDomain.

		     This  clears  the	nursery at GC time instead of doing it
		     when the thread local allocation buffer  (TLAB)  is  cre‐
		     ated.   The  default is to clear the nursery at TLAB cre‐
		     ation time.

		     Don't do minor collections.  If the nursery  is  full,  a
		     major collection is triggered instead, unless it, too, is

		     Don't do major collections.

		     Forces the GC to scan the stack conservatively,  even  if
		     precise scanning is available.

		     Disables the managed allocator.

		     If	 set,  does  a	plausibility  check on the scan_starts
		     before and after each collection

		     If set, does a complete object walk of the nursery at the
		     start of each minor collection.

		     If set, dumps the contents of the nursery at the start of
		     each minor collection. Requires  verify-nursery-at-minor-
		     gc to be set.

		     Dumps the heap contents to the specified file.   To visu‐
		     alize the information, use the mono-heapviz tool.

		     Outputs the debugging output to the specified file.   For
		     this  to  work,  Mono  needs  to  be  compiled  with  the
		     BINARY_PROTOCOL define on sgen-gc.c.   You can  then  use
		     this command to explore the output
				     sgen-grep-binprot 0x1234 0x5678 < file

	      Provides	a  prefix the runtime uses to look for Global Assembly
	      Caches.  Directories are separated by the platform path  separa‐
	      tor  (colons  on	unix). MONO_GAC_PREFIX should point to the top
	      directory of a prefixed install. Or to the directory provided in
	      the    gacutil	/gacdir	   command.    Example:	   /home/user‐

	      Enables some filename rewriting support to assist	 badly-written
	      applications that hard-code Windows paths.  Set to a colon-sepa‐
	      rated list of "drive" to strip drive letters, or	"case"	to  do
	      case-insensitive	file  matching	in  every directory in a path.
	      "all" enables all rewriting methods.   (Backslashes  are	always
	      mapped to slashes if this variable is set to a valid option).
	      For example, this would work from the shell:

		   export MONO_IOMAP

	      If you are using mod_mono to host your web applications, you can
	      use the MonoIOMAP directive instead, like this:

		   MonoIOMAP <appalias> all

	      See mod_mono(8) for more details.

	      Additionally. Mono includes a profiler module which  allows  one
	      to track what adjustements to file paths IOMAP code needs to do.
	      The tracking code	 reports  the  managed	location  (full	 stack
	      trace)  from  which  the	IOMAP-ed call was made and, on process
	      exit, the locations where all the IOMAP-ed strings were  created
	      in  managed code. The latter report is only approximate as it is
	      not always possible to estimate the actual  location  where  the
	      string  was  created.  The code uses simple heuristics - it ana‐
	      lyzes stack trace leading back to the string allocation location
	      and  ignores  all	 the  managed  code  which lives in assemblies
	      installed in GAC as well as in the class libraries shipped  with
	      Mono  (since  they  are  assumed	to be free of case-sensitivity
	      issues). It then reports the first location in the user's code -
	      in  most	cases this will be the place where the string is allo‐
	      cated or very close to  the  location.  The  reporting  code  is
	      implemented  as  a  custom  profiler module (see the "PROFILING"
	      section) and can be loaded in the following way:

		   mono --profile=iomap yourapplication.exe

	      Note, however, that Mono currently supports  only	 one  profiler
	      module at a time.

	      When  Mono is using the LLVM code generation backend you can use
	      this environment variable to pass code generation options to the
	      LLVM compiler.

	      If  set  to  "disabled",	System.IO.FileSystemWatcher will use a
	      file watcher  implementation  which  silently  ignores  all  the
	      watching	 requests.    If   set	 to   any  other  value,  Sys‐
	      tem.IO.FileSystemWatcher will use the default managed  implemen‐
	      tation  (slow).  If  unset,  mono	 will try to use inotify, FAM,
	      Gamin, kevent under Unix systems and native API  calls  on  Win‐
	      dows, falling back to the managed implementation on error.

	      Mono  supports  a	 plugin	 model	for its implementation of Sys‐
	      tem.Messaging making it possible to support a variety of messag‐
	      ing  implementations  (e.g.  AMQP,  ActiveMQ).  To specify which
	      messaging implementation is to be used the evironement  variable
	      needs  to	 be set to the full class name for the provider.  E.g.
	      to use the  RabbitMQ  based  AMQP	 implementation	 the  variable
	      should be set to:


	      If set causes the mono process to be bound to a single processor. This may be
	      useful when debugging or working around race conditions.

	      Disable inlining of thread local accesses. Try setting this if you get a segfault
	      early on in the execution of mono.

	      Provides a search path to the runtime where to look for library
	      files.   This is a tool convenient for debugging applications, but
	      should not be used by deployed applications as it breaks the assembly
	      loader in subtle ways.
	      Directories are separated by the platform path separator (colons on unix). Example:
	      Alternative solutions to MONO_PATH include: installing libraries into
	      the Global Assembly Cache (see gacutil(1)) or having the dependent
	      libraries side-by-side with the main executable.
	      For a complete description of recommended practices for application
	      deployment, see

	      Experimental RTC support in the statistical profiler: if the user has
	      the permission, more accurate statistics are gathered.  The MONO_RTC
	      value must be restricted to what the Linux rtc allows: power of two
	      from 64 to 8192 Hz. To enable higher frequencies like 4096 Hz, run as root:

		   echo 4096 > /proc/sys/dev/rtc/max-user-freq

	      For example:

		   MONO_RTC=4096 mono --profiler=default:stat program.exe

	      If  set  its  the	 directory  where  the ".wapi" handle state is
	      stored.  This is the directory where the Windows	I/O  Emulation
	      layer  stores  its  shared  state	 data (files, events, mutexes,
	      pipes).  By default Mono will store the ".wapi" directory in the
	      users's home directory.

	      Uses  the string value of this variable as a replacement for the
	      host name when creating file names  in  the  ".wapi"  directory.
	      This  helps  if  the  host  name of your machine is likely to be
	      changed when a mono application is running  or  if  you  have  a
	      .wapi  directory shared among several different computers.  Mono
	      typically uses the hostname to create the files that are used to
	      share  state  across  multiple  Mono processes.  This is done to
	      support home directories that might be shared over the network.

	      If set, extra checks are made during IO operations.   Currently,
	      this includes only advisory locks around file writes.

	      The  name	 of the theme to be used by Windows.Forms.   Available
	      themes today include  "clearlooks",  "nice"  and	"win32".   The
	      default is "win32".

	      The  time,  in seconds, that the SSL/TLS session cache will keep
	      it's entry to avoid a new negotiation between the client	and  a
	      server.  Negotiation  are	 very CPU intensive so an application-
	      specific custom value may prove useful for small	embedded  sys‐
	      tems.  The default is 180 seconds.

	      The  maximum number of threads in the general threadpool will be
	      20 + (MONO_THREADS_PER_CPU * number of CPUs). The default	 value
	      for this variable is 10.

	      Controls the threshold for the XmlSerializer to produce a custom
	      serializer for a given class instead of  using  the  Reflection-
	      based  interpreter.  The possible values are `no' to disable the
	      use of a custom serializer or a  number  to  indicate  when  the
	      XmlSerializer  should  start serializing.	  The default value is
	      50, which means that the a custom serializer will be produced on
	      the 50th use.

	      Sets the revocation mode used when validating a X509 certificate
	      chain (https, ftps, smtps...).  The default is 'nocheck',	 which
	      performs	no  revocation check at all. The other possible values
	      are 'offline', which performs CRL check  (not  implemented  yet)
	      and  'online'  which  uses OCSP and CRL to verify the revocation
	      status (not implemented yet).

	      If set to any value, temporary source files generated by ASP.NET
	      support  classes	will  not be removed. They will be kept in the
	      user's temporary directory.

	      If set, enables some features of the runtime useful  for	debug‐
	      ging.   This  variable  should contain a comma separated list of
	      debugging options.  Currently, the following  options  are  sup‐

		     If	 this  variable	 is  set, when the Mono VM runs into a
		     verification problem, instead of throwing an exception it
		     will break into the debugger.  This is useful when debug‐
		     ging verifier problems

	      casts  This option can be used to get more detailed  information
		     from  InvalidCast exceptions, it will provide information
		     about the types involved.

		     Collects information about	 pagefaults.	This  is  used
		     internally to track the number of page faults produced to
		     load metadata.  To display this information you must  use
		     this option with "--stats" command line option.

		     This  is an Optimization for multi-AppDomain applications
		     (most commonly ASP.NET applications).   Due  to  internal
		     limitations  Mono,	 Mono  by  default  does not use typed
		     allocations on multi-appDomain applications as they could
		     leak  memory when a domain is unloaded.  Although this is
		     a fine default, for applications that use	more  than  on
		     AppDomain	heavily (for example, ASP.NET applications) it
		     is worth trading off the small leaks  for	the  increased
		     performance (additionally, since ASP.NET applications are
		     not likely going to unload	 the  application  domains  on
		     production systems, it is worth using this feature).

		     Instructs	the  runtime  to try to use a generic runtime-
		     invoke wrapper instead of creating one invoke wrapper.

	      gdb    Equivalent to  setting  the  MONO_XDEBUG  variable,  this
		     emits  symbols into a shared library as the code is JITed
		     that can be loaded into GDB to inspect symbols.

		     Automatically generates  sequence	points	where  the  IL
		     stack  is empty.  These are places where the debugger can
		     set a breakpoint.

		     Makes the JIT generate an explicit NULL check on variable
		     dereferences instead of depending on the operating system
		     to raise a SIGSEGV or another form of trap event when  an
		     invalid memory location is accessed.

		     Captures  the interrupt signal (Control-C) and displays a
		     stack trace when pressed.	Useful to find out  where  the
		     program  is  executing  at a given point.	This only dis‐
		     plays the stack trace of a single thread.

		     Instructs the runtime to initialize the stack  with  some
		     known values (0x2a on x86-64) at the start of a method to
		     assist in debuggin the JIT engine.

		     This option will leak delegate trampolines	 that  are  no
		     longer referenced as to present the user with more infor‐
		     mation about a delegate  misuse.	Basically  a  delegate
		     instance  might be created, passed to unmanaged code, and
		     no references kept in managed code,  which	 will  garbage
		     collect  the  code.   With	 this option it is possible to
		     track down the source of the problems.

		     This option will cause mono to abort with	a  descriptive
		     message when during stack unwinding after an exception it
		     reaches a native stack frame. This happens when a managed
		     delegate  is passed to native code, and the managed dele‐
		     gate throws an  exception.	 Mono  will  normally  try  to
		     unwind  the  stack	 to the first (managed) exception han‐
		     dler, and it will skip any native	stack  frames  in  the
		     process.  This  leads  to undefined behaviour (since mono
		     doesn't know how to process native	 frames),  leaks,  and
		     possibly crashes too.

		     This option will disable the GDB backtrace emitted by the
		     runtime after a SIGSEGV or SIGABRT in unmanaged code.

		     This option  will	suspend	 the  program  when  a	native
		     SIGSEGV  is  received.   This  is	useful	for  debugging
		     crashes which do not  happen  under  gdb,	since  a  live
		     process contains more information than a core file.

	      The  logging  level,  possible  values  are `error', `critical',
	      `warning', `message', `info' and	`debug'.   See	the  DEBUGGING
	      section for more details.

	      Controls	the domain of the Mono runtime that logging will apply
	      to.  If set, the log mask is changed to the set value.  Possible
	      values  are  "asm"  (assembly  loader),  "type",	"dll"  (native
	      library loader), "gc" (garbage collector),  "cfg"	 (config  file
	      loader), "aot" (precompiler), "security" (e.g. Moonlight CoreCLR
	      support) and "all".  The default value is	 "all".	 Changing  the
	      mask  value  allows  you	to display only messages for a certain
	      component. You can use multiple masks by comma separating	 them.
	      For example to see config file messages and assembly loader mes‐
	      sages set you mask to "asm,cfg".

	      Used for runtime tracing of method  calls.  The  format  of  the
	      comma separated trace options is:

		   [-]M:method name
		   [-]T:class name
		   disabled	  Trace output off upon start.

	      You  can	toggle trace output on/off sending a SIGUSR2 signal to
	      the program.

	      If  set,	enables	 the  System.Diagnostics.DefaultTraceListener,
	      which  will print the output of the System.Diagnostics Trace and
	      Debug classes.  It can be set to a filename, and to  Console.Out
	      or  Console.Error	 to display output to standard output or stan‐
	      dard error, respectively. If it's set  to	 Console.Out  or  Con‐
	      sole.Error  you  can append an optional prefix that will be used
	      when writing messages  like  this:  Console.Error:MyProgramName.
	      See  the	System.Diagnostics.DefaultTraceListener	 documentation
	      for more information.

	      This eases WCF diagnostics functionality by simply  outputs  all
	      log  messages  from WCF engine to "stdout", "stderr" or any file
	      passed to this environment variable. The log format is the  same
	      as usual diagnostic output.

	      This  throws  an	exception  when a X11 error is encountered; by
	      default a message is displayed but execution continues

	      Set this value to 1 to prevent the serializer from removing  the
	      temporary	 files	that are created for fast serialization;  This
	      might be useful when debugging.

	      This is used in  the  System.Windows.Forms  implementation  when
	      running with the X11 backend.  This is used to debug problems in
	      Windows.Forms as it forces all  of  the  commands	 send  to  X11
	      server to be done synchronously.	 The default mode of operation
	      is asynchronous which makes it hard to isolate the root of  cer‐
	      tain problems.

	      This  environment	 variable controls the kind of generic sharing
	      used.  This variable is used  by	internal  JIT  developers  and
	      should  not be changed in production.  Do not use it.  The vari‐
	      able controls which  classes  will  have	generic	 code  sharing
	      enabled.	Permissible values are:

	      all    All generated code can be shared.

		     Only  the classes in System.Collections.Generic will have
		     its code shared (this is the default value).

	      corlib Only code in corlib will have its code shared.

	      none   No generic code sharing will be performed.
       Generic code sharing by default only applies to collections.   The Mono
       JIT by default turns this on.

	      When the the MONO_XDEBUG env var is set, debugging info for JIT‐
	      ted code is emitted into a shared library,  loadable  into  gdb.
	      This  enables,  for  example,  to see managed frame names on gdb

	      Enables the maximum JIT verbosity for the specified method. This
	      is very helpfull to diagnose a miscompilation problems of a spe‐
	      cific method.

	      If set, makes the JIT output information about detected CPU fea‐
	      tures (such as SSE, CMOV, FCMOV, etc) to stdout.

       If you want to use Valgrind, you will find the file `mono.supp' useful,
       it contains the suppressions for the GC which trigger  incorrect	 warn‐
       ings.  Use it like this:
	   valgrind --suppressions=mono.supp mono ...

       On  some	 platforms, Mono can expose a set of DTrace probes (also known
       as user-land statically defined, USDT Probes).

       They are defined in the file `mono.d'.

       ves-init-begin, ves-init-end
	      Begin and end of runtime initialization.

       method-compile-begin, method-compile-end
	      Begin and end of method compilation.  The	 probe	arguments  are
	      class  name,  method  name and signature, and in case of method-
	      compile-end success or failure of compilation.

       gc-begin, gc-end
	      Begin and end of Garbage Collection.

       To verify the availability of the probes, run:
		  dtrace -P mono'$target' -l -c mono

       Mono's Ping implementation for detecting network reachability can  cre‐
       ate  the	 ICMP packets itself without requiring the system ping command
       to do the work.	If you want to	enable	this  on  Linux	 for  non-root
       users, you need to give the Mono binary special permissions.

       As root, run this command:
	  # setcap cap_net_raw=+ep /usr/bin/mono

       On  Unix assemblies are loaded from the installation lib directory.  If
       you set `prefix' to /usr, the assemblies will be located	 in  /usr/lib.
       On Windows, the assemblies are loaded from the directory where mono and
       mint live.

	      The directory for the  ahead-of-time  compiler  demand  creation
	      assemblies are located.

       /etc/mono/config, ~/.mono/config
	      Mono  runtime configuration file.	 See the mono-config(5) manual
	      page for more information.

       ~/.config/.mono/certs, /usr/share/.mono/certs
	      Contains Mono certificate stores for users /  machine.  See  the
	      certmgr(1) manual page for more information on managing certifi‐
	      cate stores and the mozroots(1) page for information on  how  to
	      import  the  Mozilla root certificates into the Mono certificate

	      Files in this directory allow a user to customize the configura‐
	      tion  for	 a  given  system  assembly,  the  format  is  the one
	      described in the mono-config(5) page.

       ~/.config/.mono/keypairs, /usr/share/.mono/keypairs
	      Contains Mono cryptographic keypairs for users /	machine.  They
	      can  be  accessed	 by using a CspParameters object with DSACryp‐
	      toServiceProvider and RSACryptoServiceProvider classes.

       ~/.config/.isolatedstorage,	      ~/.local/share/.isolatedstorage,
	      Contains	Mono  isolated	storage for non-roaming users, roaming
	      users and local machine. Isolated storage can be accessed	 using
	      the classes from the System.IO.IsolatedStorage namespace.

	      Configuration information for individual assemblies is loaded by
	      the runtime from side-by-side files with the .config files,  see
	      the for more information.

       Web.config, web.config
	      ASP.NET  applications  are  configured  through these files, the
	      configuration is done on a per-directory basis.  For more infor‐
	      mation  on this subject see the‐
	      fig_system.web page.

       Mailing	lists  are  listed  at	the‐


       certmgr(1),  csharp(1),	mcs(1),	 mdb(1), monocov(1), monodis(1), mono-
       config(5),   mozroots(1),    mprof-report(1),	pdb2mdb(1),    xsp(1),

       For more information on AOT:

       For ASP.NET-related documentation, see the xsp(1) manual page

								Mono(Mono 3.0)

List of man pages available for ElementaryOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net