mono man page on Ubuntu

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

Mono(Mono 2.4)							Mono(Mono 2.4)

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

SYNOPSIS
       mono [options] file [arguments...]

DESCRIPTION
       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.

PORTABILITY
       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.

RUNTIME OPTIONS
       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:

	      bind-to-runtime-version
		     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.

	      write-symbols
		     Instructs	the AOT compiler to emit debug symbol informa‐
		     tion.

	      static Create an ELF object file (.o) which  can	be  statically
		     linked  into  an  executable when embedding the mono run‐
		     time. 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);

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

       --attach=[options]
	      Currently	 the  only option supported by this command line argu‐
	      ment is disable which disables the attach functionality.

       --full-aot
	      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.

       --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.

       --desktop
	      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.

       --help, -h
	      Displays usage instructions.

       --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‐
	      mented:
			   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:
		   -O=all,-deadce,-inline
	      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.

       --runtime=VERSION
	      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.

	      core-clr
		     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-
		     project.com/Moonlight for more details and links  to  the
		     descriptions of this new system.

	      validil
		     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.

	      verifiable
		     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‐
		     time.

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

       --server
	      Configures the virtual machine to be better  suited  for	server
	      operations (currently, a no-op).

       --verify-all
	      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).

DEVELOPMENT OPTIONS
       The following options are used to help when developing a JITed applica‐
       tion.

       --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.

	      mdb-optimizations
		     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
		     mdb.

       --profile[=profiler[:profiler_args]]
	      Turns on profiling.  For more information about profiling appli‐
	      cations and code coverage see the sections "PROFILING" and "CODE
	      COVERAGE" below.

       --trace[=expression]
	      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

	      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

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

		   mono --trace=N:System.Xml

       --no-x86-stack-align
	      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.

JIT MAINTAINER OPTIONS
       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.

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

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

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

       --graph=TYPE METHOD
	      This  generates  a postscript file with a graph with the details
	      about the specified  method  (namespace.name:methodname).	  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.

       --ncompile
	      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.

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

       --wapi=hps|semdel
	      Perform  maintenance  of	the  process shared data.  semdel will
	      delete the global semaphore.  hps will list the  currently  used
	      handles.

       -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.).

ATTACH SUPPORT
       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
       assembly.

       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.

PROFILING
       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:

	    --profile[=profiler[:profiler_args]]

       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‐
       ple:

	    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).

LOGGING PROFILER
       The logging profiler will eventually replace the default profiler as it
       is more complete and encompasses the functionality  of  all  the	 other
       profilers for Mono.  It supports the following execution modes:

	      Statistical:  the	 program  instruction  pointer is periodically
	      sampled (it works also with unmanaged functions). If call chains
	      are requested, for each sample the profiler gets a partial stack
	      trace (up to a desired depth) so that caller-callee  information
	      is available.

	      Instrumenting: each method enter and exit is logged with a time‐
	      stamp; further processing of the data can show the methods  that
	      took the longer to execute, with complete accounting for callers
	      and callees. However, this way of profiling is rather  intrusive
	      and slows down the application significantly.

	      Allocation: each allocation is logged.

	      Allocation summary: shows, for each collection, a summary of the
	      heap contents broken down by class (for each class the number of
	      allocated	 and  released	objects	 is given, together with their
	      aggregated size in bytes).

	      Heap snapshot mode: dumps the whole heap contents at every  col‐
	      lection  (or at user specified collections). It is also possible
	      to request a collection and snapshot dump with a signal.

       Moreover, other events can be logged and analyzed, like	jit  time  for
       each method, load and unload for assemblies, modules and and individual
       classes, and appdomain and thread creation and destruction.

       Instead of reporting the collected information at the end of the execu‐
       tion  of	 the  program,	this profiler logs all the events periodically
       into a file during program  execution.	To  minimize  the  performance
       impact  with  multi-threaded  applications, the logging uses per-thread
       buffers that are routinely saved to disk.

       The output file contains compressed events, to  process	the  data  you
       should use tools like the "Mono.Profiler" tool provided on the Mono SVN
       repository.

       This profiler is activated passing the --profile=logging option to  the
       mono  runtime, and is controlled attaching further options, like --pro‐
       file=logging:statistical	 for  doing  statistical  profiling  (multiple
       options are separated by commas).

       As  a  quick  primer,  here are a few examples of the most common usage
       modes:

       To write the resulting data to "mydata.mprof" (defaults to  statistical
       profiling):

	    mono --profile=logging:output=mydata.mprof program.exe

       To perform statistical profiling, inspecting call chains up to depth 8:

	    mono --profile=logging:statistical=8 program.exe

       To  profile allocations (by default the call stack will be analized for
       each allocation, producing detailed caller method attribution  inforna‐
       tion):

	    mono --profile=logging:allocations program.exe

       To profile garbage collection activity at a high level (collection time
       and objects freed at each collection for each class are	reported,  but
       heap snapshots are not saved to disk):

	    mono --profile=logging:allocations-summary program.exe

       To perform heap profiling taking heap snapshots:

	    mono --profile=logging:heap=all program.exe
	    mono --profile=logging:heap=<signal> program.exe

       If  "all"  is  specified,  a heap snapshot is taken at each collection.
       If, instead, a signal name or number is given (one of SIGUSR1,  SIGUSR2
       and  SIGPROF,  remembering that SIGPROF is not compatible with the sta‐
       tistical profiler), a garbage collection is forced and  a  snapshot  is
       taken  every  time the signal is received.  Heap profiling also enables
       full allocation profiling (with call stacks), and each  allocation  can
       be  related  to	its  corresponding  object  in the snapshots, enabling
       investigations like "find all objects of a given class allocated	 by  a
       given  method  and  still live at a given collection, and then find all
       objects referencing them".

       Then you would need to invoke the decoder mprof-decoder(1) on the  out‐
       put file to see the profiling results, or to examine heap snapshots and
       allocations in detail mprof-heap-viewer(1).

       The operating modes described above are the default ones, and are  suf‐
       ficient to use the profiler.

       To  further  customize  the  profiler  behavior there are more options,
       described below.	 These options can be individually  enabled  and  dis‐
       abled  prefixing them with an (optional) '+' character or a '-' charac‐
       ter.  For instance, the "allocations" option by	default	 records  also
       the  full call stack at each allocation.	 If only the caller is wanted,
       one should use "allocations,-save-allocation-stack", or to disable call
       tracking	 completely  (making  the  profiler  less  intrusive) "alloca‐
       tions,-save-allocation-caller,-save-allocation-stack".  In practice the
       "allocation"  option  by default behaves like "allocations,save-alloca‐
       tion-caller,save-allocation-stack", but the user can tune this  to  his
       needs.

       These are all the available options, organized by category:

       Execution profiling modes

	      statistical, stat or s
		     Performs  statistical  profiling.	 This is a lightweight
		     profiling mechanism and it has a much lower overhead than
		     the  enter-leave  profiling as it works by sampling where
		     the program is spending its time by using	a  timer.   If
		     specified with s=<number>, also inspect call chains up to
		     level <number>.

	      enter-leave, calls or c
		     Measure the time spent inside each method call,  this  is
		     done  by  logging	the time when a method enters and when
		     the method leaves.	 This can be a time  consuming	opera‐
		     tion.

	      jit, j Collect  information  about  time spent by the JIT engine
		     compiling methods.

       Allocation profiling modes

	      allocations, alloc or a
		     Collect information about each allocation	(object	 class
		     and  size).   By default this also implies "+save-alloca‐
		     tion-caller" and "+save-allocation-stack".

	      save-allocation-caller, sac
		     Save the direct caller of each allocation.	 The  profiler
		     filters  out  wrapper methods, and also recognizes if the
		     allocation has been performed by the runtime  while  jit‐
		     ting a method.

	      save-allocation-stack, sas
		     Save the full managed execution stack at each allocation.
		     While the "sac" option saves the direct caller, this  one
		     records  the  whole  stack	 trace.	 Note that in the call
		     stack the wrapper methods are not filtered	 out.	Anyway
		     the  "sac"	 and  "sas"  options  can be combined, and the
		     decoder will attribute  the  allocation  to  the  correct
		     method  even  if  the  wrapper is at the top of the stack
		     trace.

	      allocations-summary or as
		     At each collection dump a summary of  the	heap  contents
		     (for  each	 class,	 the number and collective size of all
		     live and freed heap objects). This very lightweight  com‐
		     pared to full heap snapshots.

	      unreachable, free or f
		     Performs  a lightweight profile of the garbage collector.
		     On each collection performed  by  the  GC,	 the  list  of
		     unreachable  objects is recorded, and for each object the
		     class and size is provided.  This information can be used
		     to	 compute  the heap size broken down by class (combined
		     with "a" can give the same information of "as",  but  the
		     log  file	contains  info	about  each individual object,
		     while in "as" the processing is done directly at  runtime
		     and the log file contains only the summarized data broken
		     down by class).

	      gc or g
		     Measure the time spent in each collection, and also trace
		     heap resizes.

	      heap-shot, heap or h
		     Performs full heap profiling.   In this case on each col‐
		     lection a full heap snapshot is recorded to disk.	Inside
		     the snapshots, each object reference is still represented
		     so that it's possible to investigate who  is  responsible
		     for keeping objects alive.

	      The  actual production of heap snapshots could produce large log
	      files, so it can be controlled in three ways:

	      gc-dumps=N, gc-d=N, gcd=N
		     states the number of snapshots that must be dumped (since
		     the  application  starts). Zero means no dumps at all, -1
		     means dump at all collections.

	      gc-signal=<signal>, gc-s or gcs
		     (where <signal> is one of "SIGUSR1", "SIGUSR2", or	 "SIG‐
		     PROF") specifies a signal that will immediately trigger a
		     collection and a dump.

	      gc-commands=FILE, gc-c=FILE or gcc=FILE
		     specify a "command file". The file must contain an	 inte‐
		     ger value in ASCII form, and the profiler will stat it at
		     every collection.	If it has been modified it will inter‐
		     pret  its	contents as a gcd=N option value, and dump the
		     required number of snapshots from	that  moment  onwards.
		     If	 the  file  is present at application startup it takes
		     precedence over an eventual gcd=N option.

       Profiler activity control

	      output=FILE, out=FILE or o=FILE
		     Use this option to provide the output file name  for  the
		     profile  log.   If	 this option is not specified, it will
		     default to "<program-name>.mprof".

	      output-suffix=SUFFIX, suffix=SUFFIX or os=SUFFIX: makes
		     the  output  file	name  equals  to  "<program-name>-SUF‐
		     FIX.mprof".

	      start-enabled or se: start with the profiler active
		     (which is the default).

	      start-disabled or sd: start with the profiler inactive.

	      toggle-signal=<SIGNAL> or ts=<SIGNAL> (where <SIGNAL>
		     is	 one  of SIGUSR1, SIGUSR2 or SIGPROF): Choose a signal
		     that will be used to toggle the profiler activity on  and
		     off.  This way you can decide to profile only portions of
		     the applicatopn lifetime (for instance, you can decide to
		     avoid  profiling  an  initial  setup  phase using sd, and
		     enable the profiler later delivering the  signal  to  the
		     application).

	      force-accurate-timer (or fac): the profiler by default uses
		     rtdsc to acquire timestamps for frequent events, but this
		     can be imprecise; using this option you force the use  of
		     "gettimeofday" at every event, which is more accurate but
		     much slower.

       Internal buffer sizes

	      per-thread-buffer-size=N, tbs=N
		     Use to specify the number of events that a thread	buffer
		     can  hold.	   When the thread buffer is full, a log block
		     is written to disk.  This defaults to tbs=10000.

	      statistical-thread-buffer-size=N, sbs=N
		     The number of statistical samples that are held in memory
		     before  they  are dumped to disk (the system does double-
		     buffering and the statistical samples are	written	 by  a
		     helper  thread,  so  the statistical profiler never stops
		     and is  able  to  profile	the  profiler  itself).	  This
		     defaults to sbs=10000.

	      write-buffer-size, wbs
		     Specifies	the  size  in bytes of the internal write buf‐
		     fers.  This defaults to wbs=1024.

       In its current state, this profiler  can	 also  perform	heap  analysis
       (like  heap-shot),  and	the  decoder is already able to read the data,
       however the user interface for this feature is experimental (the mprof-
       heap-viewer tool in the mono-tools module).

       Another	known  issue  is  that	if the timer is not strictly monotonic
       (like rtdsc), differences between times can underflow (they are handled
       as unsigned integers) and weird numbers can show up in the logs.

       Finally,	 it  can  happen  that when exceptions are thrown the profiler
       temporarily loses track of the execution stack  and  misattributes  the
       caller for a few allocations (and method execution time).

       More  explanations are provided here: "http://www.mono-project.com/Log‐
       gingProfiler".

EXTERNAL PROFILERS
       There are a number of external profilers that have been	developed  for
       Mono, we will update this section to contain the profilers.

       The  heap  Shot	profiler can track all live objects, and references to
       these objects, and includes a GUI tool, this is	our  recommended  pro‐
       filer.  To install you must download the profiler from Mono's SVN:
	    svn co svn://anonsvn.mono-project.com/source/trunk/heap-shot
	    cd heap-shot
	    ./autogen
	    make
	    make install

       See the included documentation for details on using it.

       The  Live  Type	profiler  shows	 at every GC iteration all of the live
       objects of a given type.	  To install you must  download	 the  profiler
       from Mono's SVN:
	    svn co svn://anonsvn.mono-project.com/source/trunk/heap-prof
	    cd heap-prof
	    ./autogen
	    make
	    make install

       To use the profiler, execute:
	    mono --profile=desc-heap program.exe

       The output of this profiler looks like this:
	    Checkpoint at 102 for heap-resize
	       System.MonoType : 708
	       System.Threading.Thread : 352
	       System.String : 3230
	       System.String[] : 104
	       Gnome.ModuleInfo : 112
	       System.Object[] : 160
	       System.Collections.Hashtable : 96
	       System.Int32[] : 212
	       System.Collections.Hashtable+Slot[] : 296
	       System.Globalization.CultureInfo : 108
	       System.Globalization.NumberFormatInfo : 144

       The  first line describes the iteration number for the GC, in this case
       checkpoint 102.

       Then on each line the type is displayed as well as the number of	 bytes
       that are being consumed by live instances of this object.

       The  AOT	 profiler is used to feed back information to the AOT compiler
       about how to order code based on the access patterns for pages.	To use
       it, use:
	    mono --profile=aot program.exe
       The  output of this profile can be fed back into Mono's AOT compiler to
       order the functions on the disk to produce precompiled images that have
       methods in sequential pages.

CUSTOM PROFILERS
       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 `mono-profiler-custom.so'.  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
       (www.mono-project.com/Performance_Tips)

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

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

CODE COVERAGE
       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"
       assembly:

	    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
       namespace:

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

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

       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.

DEBUGGING AIDS
       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
       guaranteed.

       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
       afterwards.

       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)  and  "all".  The default value is "all". Changing
       the mask value allows you to display only messages for a certain compo‐
       nent.  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

SERIALIZATION
       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‐
       able.

       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).

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

       MONO_AOT_CACHE
	      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_CFG_DIR
	      If set, this variable overrides the default system configuration
	      directory ($PREFIX/etc).	It's  used  to	locate	machine.config
	      file.

       MONO_COM
	      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.

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

       MONO_DEBUG
	      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‐
	      ported:

	      break-on-unverified
		     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

	      collect-pagefault-stats
		     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.

	      dont-free-domains
		     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).

	      handle-sigint
		     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.

	      keep-delegates
		     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.

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

       MONO_DISABLE_AIO
	      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.

       MONO_DISABLE_MANAGED_COLLATION
	      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.

       MONO_EGD_SOCKET
	      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.

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

	      local[:path]
		     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).

       MONO_EXTERNAL_ENCODINGS
	      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
	      encoding.

	      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.

       MONO_GAC_PREFIX
	      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‐
	      name/.mono:/usr/local/mono/

       MONO_IOMAP
	      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:

		   MONO_IOMAP=drive:case
		   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.

       MONO_MANAGED_WATCHER
	      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_NO_SMP
	      If  set  causes the mono process to be bound to a single proces‐
	      sor. This may be useful when debugging or	 working  around  race
	      conditions.

       MONO_PATH
	      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:
	      /home/username/lib:/usr/local/mono/lib 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
	      http://www.mono-project.com/Guidelines:Application_Deployment

       MONO_RTC
	      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  fre‐
	      quencies 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

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

       MONO_SHARED_DIR
	      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.

       MONO_SHARED_HOSTNAME
	      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.

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

       MONO_DISABLE_SHM
	      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 con‐
	      figure.

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

       MONO_TLS_SESSION_CACHE_TIMEOUT
	      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.

       MONO_THREADS_PER_CPU
	      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.

       MONO_XMLSERIALIZER_THS
	      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.

       MONO_XMLSERIALIZER_DEBUG
	      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.

       MONO_ASPNET_INHIBIT_SETTINGSMAP
	      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/settings.map  file and, optionally, in the set‐
	      tings.map 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.

ENVIRONMENT VARIABLES FOR DEBUGGING
       MONO_ASPNET_NODELETE
	      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.

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

       MONO_LOG_MASK
	      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)  and "all".  The default value is
	      "all". Changing the mask value allows you to display  only  mes‐
	      sages  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".

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

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

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

       MONO_TRACE_LISTENER
	      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.

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

       MONO_XSYNC
	      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.

       MONO_GENERIC_SHARING
	      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.

	      collections
		     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.

       MONO_XDEBUG
	      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
	      backtraces.

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

VALGRIND
       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 ...

DTRACE
       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

FILES
       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.

       ~/.mono/aot-cache
	      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
	      store.

       ~/.mono/assemblies/ASSEMBLY/ASSEMBLY.config
	      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,
       /usr/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.

       <assembly>.config
	      Configuration information for individual assemblies is loaded by
	      the runtime from side-by-side files with the .config files,  see
	      the http://www.mono-project.com/Config 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 http://www.mono-project.com/Con‐
	      fig_system.web page.

MAILING LISTS
       Mailing	lists  are  listed  at	the  http://www.mono-project.com/Mail‐
       ing_Lists

WEB SITE
       http://www.mono-project.com

SEE ALSO
       certmgr(1),  csharp(1),	mcs(1),	 mdb(1), monocov(1), monodis(1), mono-
       config(5), mozroots(1), pdb2mdb(1), xsp(1), mod_mono(8).

       For more information on AOT: http://www.mono-project.com/AOT

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

								Mono(Mono 2.4)
[top]

List of man pages available for Ubuntu

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]
Tweet
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