Provided by: mono-runtime_2.10.8.1-1ubuntu2_i386 bug


       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
       Infrastructure.  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
       dynamically 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
       arguments 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
       debugging 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
       Windows-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
              independent code.  Pre compilation is just a mechanism to reduce
              startup   time,  increase  code  sharing  across  multiple  mono
              processes 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-generated 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
              commas, and more than one can be specified:

                     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
                     precompiled with AOT.

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

                     Instructs   the   AOT   compiler  to  emit  debug  symbol

                     Instructs the AOT compiler to keep temporary files.

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

                     Instructs  the  AOT  compiler to not output any debugging

                     When compiling in full aot mode, the  method  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 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 IMT trampolines must
                     be  precreated  in the AOT image.  You can add additional
                     method trampolines with this argument.  Defaults to 128.

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

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

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

                     This instructs the compiler to  generate  sequence  point
                     checks   that   allow   Mono's  soft  debugger  to  debug
                     applications even on systems where it is not possible  to
                     set  breakpoints  or  to  single  step  (certain hardware
                     configurations like the  cell  phones  and  video  gaming

              static Create  an  ELF  object file (.o) 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);

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

              Currently  the  only  option  supported  by  this  command  line
              argument 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/config   or   the  file  specified  in  the  MONO_CONFIG
              environment variable, 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
              interface  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

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

                     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.

              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

       --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
              optimization and code generation engine to JIT or  AOT  compile.
              For      more     information,     consult:     http://www.mono-

              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
              optimization 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
              benefits   of  using  them.   The  following  optimizations  are
                           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
              elimination 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
              compilation  (--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
              version 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

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

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

              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

       --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
                     InvalidCastException.    This  option needs to be enabled
                     as this generates 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
              applications 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
              `program', `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
              runtime.  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
              namespace, and to trace all exceptions,  specify  'all'  as  the
              type name.

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

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

              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
              Ghostview   to  be  called  "gv").   The  following  graphs  are
                        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
              generator 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
              selector 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
       various 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
       profilers, see the section "CUSTOM PROFILERS" for more details.

       If  a  profiler  is  not  specified, the default profiler is used.  The
       profiler_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

            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
       program.exe.  The  profile  data  is  put  in  prof.out.  Note that the
       statistical profiler  has  a  very  low  overhead  and  should  be  the
       preferred  profiler  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:
       --profile=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
       following  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

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

       Which  will  only  perform  code  coverage  in  the  given assembly and

       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
       command 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
       guaranteed  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), "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

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


              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
              runtime 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
              compile 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
              $prefix/etc/mono/2.0/ file and, optionally,  in  the
      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.

              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
              configuration  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
              unmanaged collation (which actually means  no  culture-sensitive
              collation).    It    internally   disables   managed   collation
              functionality     invoked      via      the      members      of
              System.Globalization.CompareInfo  class. Collation is enabled by

              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.

              For platforms that do not otherwise  have  a  way  of  obtaining
              random 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
              handles, named mutexes, named events and named semaphores across
              Unix processes.

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

              Sets  the   type   of   event   log   provider   to   use   (for
              System.Diagnostics.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\ventlog" 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
                     permission  for  individual  event  log  and event source
                     directories 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
              arguments  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
              successful 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
                     gigabytes,  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-par'
                     for parallel Mark&Sweep, `marksweep-fixed' for Mark&Sweep
                     with a fixed  heap,  `marksweep-fixed-par'  for  parallel
                     Mark&Sweep  with  a  fixed  heap  and  `copying'  for the
                     copying  collector.  The  Mark&Sweep  collector  is   the

                     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.

                     Specifies  which  write  barrier  to  use.   Options  are
                     `cardtable'  and  `remset'.   The  card  table barrier is
                     faster but less  precise,  and  only  supported  for  the
                     Mark&Sweep  major  collector  on  32  bit platforms.  The
                     default is `cardtable'  if  it  is  supported,  otherwise
                     `remset'. The cardtable write barrier is faster and has a
                     more stable and usually smaller memory footprint. If  the
                     program  causes  too  much pinning during thread scan, it
                     might be faster to enable remset.

                     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
                     collection  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 concurrent sweep for  the  Mark&Sweep
                     collector.   If  enabled,  the sweep phase of the garbage
                     collection is done in  a  thread  concurrently  with  the
                     application.  Concurrent sweep is disabled 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
                     references  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.

              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.


                     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.

                     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
                     created.  The default is to clear  the  nursery  at  TLAB
                     creation 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.

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

                     Dumps  the  heap  contents  to  the  specified file.   To
                     visualize 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
              separator  (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:

              Enables some filename rewriting support to assist  badly-written
              applications  that  hard-code  Windows  paths.   Set to a colon-
              separated 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
              analyzes 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 allocated 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,
              System.IO.FileSystemWatcher  will  use   the   default   managed
              implementation  (slow).  If unset, mono will try to use inotify,
              FAM, Gamin, kevent under Unix systems and native  API  calls  on
              Windows, falling back to the managed implementation on error.

              Mono   supports   a  plugin  model  for  its  implementation  of
              System.Messaging making it possible  to  support  a  variety  of
              messaging  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
              systems.  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
              debugging.   This variable should contain a comma separated list
              of debugging options.   Currently,  the  following  options  are

                     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
                     debugging 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
                     displays 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
                     information  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
                     delegate throws an exception. Mono will normally  try  to
                     unwind   the  stack  to  the  first  (managed)  exception
                     handler, 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
              messages 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
              standard error, respectively. If  it's  set  to  Console.Out  or
              Console.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

              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
              certain 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
              variable  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
              JITted 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
              specific method.


       If you want to use Valgrind, you will find the file `mono.supp' useful,
       it contains  the  suppressions  for  the  GC  which  trigger  incorrect
       warnings.  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
       create  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
              certificate stores and the mozroots(1) page for  information  on
              how  to  import  the  Mozilla  root  certificates  into the Mono
              certificate store.

              Files  in  this  directory  allow  a  user  to   customize   the
              configuration 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
              DSACryptoServiceProvider 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
              information   on   this   subject   see   the   http://www.mono-


       Mailing    lists     are     listed     at     the     http://www.mono-



       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:

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

                                                                Mono(Mono 2.5)