1Mono(mono) Mono(mono)
2
3
4
6 mono - Mono's ECMA-CLI native code generator (Just-in-Time and Ahead-
7 of-Time)
8
10 mono [options] file [arguments...]
11
12 mono-sgen [options] file [arguments...]
13
15 mono is a runtime implementation of the ECMA Common Language Infra‐
16 structure. This can be used to run ECMA and .NET applications.
17
18 The runtime loads the specified file and optionally passes the argu‐
19 ments to it. The file is an ECMA assembly. They typically have a .exe
20 or .dll extension.
21
22 These executables can reference additional functionality in the form of
23 assembly references. By default those assembly references are resolved
24 as follows: the mscorlib.dll is resolved from the system profile that
25 is configured by Mono, and other assemblies are loaded from the Global
26 Assembly Cache (GAC).
27
28 The runtime contains a native code generator that transforms the Common
29 Intermediate Language into native code.
30
31 The code generator can operate in two modes: Just-in-time compilation
32 (JIT) or Ahead-of-time compilation (AOT). Since code can be dynami‐
33 cally loaded, the runtime environment and the JIT are always present,
34 even if code is compiled ahead of time.
35
36 The runtime provides a number of configuration options for running
37 applications, for developing and debugging, and for testing and debug‐
38 ging the runtime itself.
39
40 The mono command uses the moving and generational SGen garbage collec‐
41 tor while the mono-boehm command uses the conservative Boehm garbage
42 collector.
43
45 On Unix-based systems, Mono provides a mechanism to emulate the Win‐
46 dows-style file access, this includes providing a case insensitive view
47 of the file system, directory separator mapping (from \ to /) and
48 stripping the drive letters.
49
50 This functionality is enabled by setting the MONO_IOMAP environment
51 variable to one of all, drive and case.
52
53 See the description for MONO_IOMAP in the environment variables section
54 for more details.
55
57 A number of diagnostic command line options take as argument a method
58 description. A method description is a textual representation that
59 can be used to uniquely identify a method. The syntax is as follows:
60 [namespace]classname:methodname[(arguments)]
61
62 The values in brackets are optional, like the namespace and the argu‐
63 ments. The arguments themselves are either empty, or a comma-sepa‐
64 rated list of arguments. Both the classname and methodname can be set
65 to the special value '*' to match any values (Unix shell users should
66 escape the argument to avoid the shell interpreting this).
67
68 The arguments, if present should be a comma separated list of types
69 either a full typename, or for built-in types it should use the low-
70 level ILAsm type names for the built-in types, like 'void', 'char',
71 'bool', 'byte', 'sbyte', 'uint16', 'int16', 'uint',
72
73 Pointer types should be the name of the type, followed by a '*', arrays
74 should be the typename followed by '[' one or more commas (to indicate
75 the rank of the array), and ']'.
76
77 Generic values should use '<', one or more type names, separated by
78 both a comma and a space and '>'.
79
80 By-reference arguments should include a "&" after the typename.
81
82 Examples:
83 *:ctor(int) // All constructors that take an int as an argument
84 *:Main // Methods named Main in any class
85 *:Main(string[]) // Methods named Main that take a string array in any class
86
88 The following options are available:
89
90 --aot, --aot[=options]
91 This option is used to precompile the CIL code in the specified
92 assembly to native code. The generated code is stored in a file
93 with the extension .so. This file will be automatically picked
94 up by the runtime when the assembly is executed. Ahead-of-Time
95 compilation is most useful if you use it in combination with the
96 -O=all,-shared flag which enables all of the optimizations in
97 the code generator to be performed. Some of those optimizations
98 are not practical for Just-in-Time compilation since they might
99 be very time consuming. Unlike the .NET Framework, Ahead-of-
100 Time compilation will not generate domain independent code: it
101 generates the same code that the Just-in-Time compiler would
102 produce. Since most applications use a single domain, this is
103 fine. If you want to optimize the generated code for use in
104 multi-domain applications, consider using the -O=shared flag.
105 This pre-compiles the methods, but the original assembly is
106 still required to execute as this one contains the metadata and
107 exception information which is not available on the generated
108 file. When precompiling code, you might want to compile with
109 all optimizations (-O=all). Pre-compiled code is position inde‐
110 pendent code. Precompilation is just a mechanism to reduce
111 startup time, increase code sharing across multiple mono pro‐
112 cesses and avoid just-in-time compilation program startup costs.
113 The original assembly must still be present, as the metadata is
114 contained there. AOT code typically can not be moved from one
115 computer to another (CPU-specific optimizations that are
116 detected at runtime) so you should not try to move the pre-gen‐
117 erated assemblies or package the pre-generated assemblies for
118 deployment. A few options are available as a parameter to the
119 --aot command line option. The options are separated by com‐
120 mas, and more than one can be specified:
121
122 asmonly
123 Instructs the AOT compiler to output assembly code
124 instead of an object file.
125
126 bind-to-runtime-version
127 If specified, forces the generated AOT files to be bound
128 to the runtime version of the compiling Mono. This will
129 prevent the AOT files from being consumed by a different
130 Mono runtime.
131
132 data-outfile=FILE.dll.aotdata
133 This instructs the AOT code generator to output certain
134 data constructs into a separate file. This can reduce
135 the executable images some five to twenty percent.
136 Developers need to then ship the resulting aotdata as a
137 resource and register a hook to load the data on demand
138 by using the mono_install_load_aot_data_hook method.
139
140 direct-icalls
141 When this option is specified, icalls (internal calls
142 made from the standard library into the mono runtime
143 code) are invoked directly instead of going through the
144 operating system symbol lookup operation. This requires
145 use of the static option.
146
147 direct-pinvoke
148 When this option is specified, P/Invoke methods are
149 invoked directly instead of going through the operating
150 system symbol lookup operation. This requires use of the
151 static option.
152
153 dwarfdebug
154 Instructs the AOT compiler to emit DWARF debugging infor‐
155 mation. When used together with the nodebug option, only
156 DWARF debugging information is emitted, but not the
157 information that can be used at runtime.
158
159 full This creates binaries which can be used with the --full-
160 aot option.
161
162 hybrid This creates binaries which can be used with the
163 --hybrid-aot option.
164
165 llvm AOT will be performed with the LLVM backend instead of
166 the Mono backend where possible. This will be slower to
167 compile but most likely result in a performance improve‐
168 ment.
169
170 llvmonly
171 AOT will be performed with the LLVM backend exclusively
172 and the Mono backend will not be used. The only output in
173 this mode will be the bitcode file normally specified
174 with the llvm-outfile option. Use of llvmonly automati‐
175 cally enables the full and llvm options. This feature is
176 experimental.
177
178 llvmopts=[options]
179 Use this option to add more flags to the built-in set of
180 flags passed to the LLVM optimizer. When you invoke the
181 mono command with the --aot=llvm it displays the current
182 list of flags that are being passed to the opt command.
183 The list of possible flags that can be passed can be
184 obtained by calling the bundled opt program that comes
185 with Mono, and calling it like this:
186
187 opt --help
188
189
190
191 llvmllc=[options]
192 Use this option to add more flags to the built-in set of
193 flags passed to the LLVM static compiler (llc). The
194 list of possible flags that can be passed can be obtained
195 by calling the bundled llc program that comes with Mono,
196 and calling it like this:
197
198 llc --help
199
200
201 mcpu=[native o generic]
202 cpu=native allows AOT mode to use all instructions cur‐
203 rent CPU supports, e.g. AVX2, SSE42, etc. Default value
204 is 'generic'. mattr=[cpu feature] Allows AOT code gener‐
205 ator to use specified CPU features where possible includ‐
206 ing `System.Runtime.Intrinsics.*'. E.g.
207 `mattr=+avx2,mattr=-lzcnt' unlocks sse1-4.2, avx1-2 and
208 disables lzcnt. It's useful for cross-compilation or
209 when it's not possible to use `-mcpu=native' (which
210 enables all cpu feature current cpu has). llvm-out‐
211 file=[filename] Gives the path for the temporary LLVM
212 bitcode file created during AOT. dedup Each AOT module
213 will typically contain the code for inflated methods and
214 wrappers that are called by code in that module. In dedup
215 mode, we identify and skip compiling all of those meth‐
216 ods. When using this mode with fullaot, dedup-include is
217 required or these methods will remain missing.
218
219 dedup-include=[filename]
220 In dedup-include mode, we are in the pass of compilation
221 where we compile the methods that we had previously
222 skipped. All of them are emitted into the assembly that
223 is passed as this option. We consolidate the many dupli‐
224 cate skipped copies of the same method into one.
225
226
227 info Print the architecture the AOT in this copy of Mono tar‐
228 gets and quit.
229
230 interp Generates all required wrappers, so that it is possible
231 to run --interpreter without any code generation at run‐
232 time. This option only makes sense with mscorlib.dll.
233 Embedders can set
234
235 depfile=[filename]
236 Outputs a gcc -M style dependency file.
237
238 mono_jit_set_aot_mode (MONO_AOT_MODE_INTERP);
239
240 ld-flags
241 Additional flags to pass to the C linker (if the current
242 AOT mode calls for invoking it).
243
244 llvm-path=<PREFIX>
245 Same for the llvm tools 'opt' and 'llc'.
246
247 msym-dir=<PATH>
248 Instructs the AOT compiler to generate offline sequence
249 points .msym files. The generated .msym files will be
250 stored into a subfolder of <PATH> named as the compila‐
251 tion AOTID.
252
253 mtriple=<TRIPLE>
254 Use the GNU style target triple <TRIPLE> to determine
255 some code generation options, i.e.
256 --mtriple=armv7-linux-gnueabi will generate code that
257 targets ARMv7. This is currently only supported by the
258 ARM backend. In LLVM mode, this triple is passed on to
259 the LLVM llc compiler.
260
261 nimt-trampolines=[number]
262 When compiling in full aot mode, the IMT trampolines must
263 be precreated in the AOT image. You can add additional
264 method trampolines with this argument. Defaults to 512.
265
266 ngsharedvt-trampolines=[number]
267 When compiling in full aot mode, the value type generic
268 sharing trampolines must be precreated in the AOT image.
269 You can add additional method trampolines with this argu‐
270 ment. Defaults to 512.
271
272 nodebug
273 Instructs the AOT compiler to not output any debugging
274 information.
275
276 no-direct-calls
277 This prevents the AOT compiler from generating a direct
278 calls to a method. The AOT compiler usually generates
279 direct calls for certain methods that do not require
280 going through the PLT (for example, methods that are
281 known to not require a hook like a static constructor) or
282 call into simple internal calls.
283
284 nrgctx-trampolines=[number]
285 When compiling in full aot mode, the generic sharing
286 trampolines must be precreated in the AOT image. You can
287 add additional method trampolines with this argument.
288 Defaults to 4096.
289
290 nrgctx-fetch-trampolines=[number]
291 When compiling in full aot mode, the generic sharing
292 fetch trampolines must be precreated in the AOT image.
293 You can add additional method trampolines with this argu‐
294 ment. Defaults to 128.
295
296 ntrampolines=[number]
297 When compiling in full aot mode, the method trampolines
298 must be precreated in the AOT image. You can add addi‐
299 tional method trampolines with this argument. Defaults
300 to 4096.
301
302 outfile=[filename]
303 Instructs the AOT compiler to save the output to the
304 specified file.
305
306 print-skipped-methods
307 If the AOT compiler cannot compile a method for any rea‐
308 son, enabling this flag will output the skipped methods
309 to the console.
310
311 profile=[file]
312 Specify a file to use for profile-guided optimization.
313 See the AOT profiler sub-section. To specify multiple
314 files, include the profile option multiple times.
315
316 profile-only
317 AOT *only* the methods described in the files specified
318 with the profile option. See the AOT profiler sub-sec‐
319 tion.
320
321 readonly-value=namespace.typename.fieldname=type/value
322 Override the value of a static readonly field. Usually,
323 during JIT compilation, the static constructor is ran
324 eagerly, so the value of a static readonly field is known
325 at compilation time and the compiler can do a number of
326 optimizations based on it. During AOT, instead, the
327 static constructor can't be ran, so this option can be
328 used to set the value of such a field and enable the same
329 set of optimizations. Type can be any of i1, i2, i4 for
330 integers of the respective sizes (in bytes). Note that
331 signed/unsigned numbers do not matter here, just the
332 storage size. This option can be specified multiple
333 times and it doesn't prevent the static constructor for
334 the type defining the field to execute with the usual
335 rules at runtime (hence possibly computing a different
336 value for the field).
337
338 save-temps,keep-temps
339 Instructs the AOT compiler to keep temporary files.
340
341 soft-debug
342 This instructs the compiler to generate sequence point
343 checks that allow Mono's soft debugger to debug applica‐
344 tions even on systems where it is not possible to set
345 breakpoints or to single step (certain hardware configu‐
346 rations like the cell phones and video gaming consoles).
347
348 static Create an ELF object file (.o) or .s file which can be
349 statically linked into an executable when embedding the
350 mono runtime. When this option is used, the object file
351 needs to be registered with the embedded runtime using
352 the mono_aot_register_module function which takes as its
353 argument the mono_aot_module_<ASSEMBLY NAME>_info global
354 symbol from the object file:
355
356 extern void *mono_aot_module_hello_info;
357
358 mono_aot_register_module (mono_aot_module_hello_info);
359
360 stats Print various stats collected during AOT compilation.
361
362 temp-path=[path]
363 Explicitly specify path to store temporary files created
364 during AOT compilation.
365
366 threads=[number]
367 This is an experimental option for the AOT compiler to
368 use multiple threads when compiling the methods.
369
370 tool-prefix=<PREFIX>
371 Prepends <PREFIX> to the name of tools ran by the AOT
372 compiler, i.e. 'as'/'ld'. For example, --tool=prefix=arm-
373 linux-gnueabi- will make the AOT compiler run
374
375 verbose
376 Prints additional information about type loading fail‐
377 ures.
378
379 write-symbols,no-write-symbols
380 Instructs the AOT compiler to emit (or not emit) debug
381 symbol information.
382
383 no-opt Instructs the AOT compiler tot no call opt when compiling
384 with LLVM.
385
386 For more information about AOT, see: http://www.mono-
387 project.com/docs/advanced/aot/
388
389 --aot-path=PATH
390 List of additional directories to search for AOT images.
391
392 --apply-bindings=FILE
393 Apply the assembly bindings from the specified configuration
394 file when running the AOT compiler. This is useful when compil‐
395 ing an auxiliary assembly that is referenced by a main assembly
396 that provides a configuration file. For example, if app.exe
397 uses lib.dll then in order to make the assembly bindings from
398 app.exe.config available when compiling lib.dll ahead of time,
399 use:
400 mono --apply-bindings=app.exe.config --aot lib.dll
401
402 --assembly-loader=MODE
403 If mode is strict, Mono will check that the public key token,
404 culture and version of a candidate assembly matches the
405 requested strong name. If mode is legacy, as long as the name
406 matches, the candidate will be allowed. strict is the behavior
407 consistent with .NET Framework but may break some existing mono-
408 based applications. The default is legacy.
409
410 --attach=[options]
411 Currently the only option supported by this command line argu‐
412 ment is disable which disables the attach functionality.
413
414 --config filename
415 Load the specified configuration file instead of the default
416 one(s). The default files are /etc/mono/config and ~/.mono/con‐
417 fig or the file specified in the MONO_CONFIG environment vari‐
418 able, if set. See the mono-config(5) man page for details on
419 the format of this file.
420
421 --debugger-agent=[options]
422 This instructs the Mono runtime to start a debugging agent
423 inside the Mono runtime and connect it to a client user inter‐
424 face will control the Mono process. This option is typically
425 used by IDEs, like the MonoDevelop or Visual Studio IDEs.
426 The configuration is specified using one of more of the follow‐
427 ing options:
428
429 address=host:port
430 Use this option to specify the IP address where
431 your debugger client is listening to.
432
433 loglevel=LEVEL
434 Specifies the diagnostics log level for
435
436 logfile=filename
437 Used to specify the file where the log will be
438 stored, it defaults to standard output.
439
440 server=[y/n]
441 Defaults to no, with the default option Mono will
442 actively connect to the host/port configured with
443 the address option. If you set it to 'y', it
444 instructs the Mono runtime to start debugging in
445 server mode, where Mono actively waits for the
446 debugger front end to connect to the Mono process.
447 Mono will print out to stdout the IP address and
448 port where it is listening.
449
450 setpgid=[y/n]
451 If set to yes, Mono will call setpgid(0, 0) on
452 startup, if that function is available on the sys‐
453 tem. This is useful for ensuring that signals
454 delivered to a process that is executing the
455 debuggee are not propagated to the debuggee, e.g.
456 when Ctrl-C sends SIGINT to the sdb tool.
457
458 suspend=[y/n]
459 Defaults to yes, with the default option Mono will
460 suspend the vm on startup until it connects suc‐
461 cessfully to a debugger front end. If you set it
462 to 'n', in conjunction with server=y, it instructs
463 the Mono runtime to run as normal, while caching
464 metadata to send to the debugger front end on con‐
465 nection..
466
467 transport=transport_name
468 This is used to specify the transport that the
469 debugger will use to communicate. It must be
470 specified and currently requires this to be
471 'dt_socket'.
472
473 --desktop
474 Configures the virtual machine to be better suited for
475 desktop applications. Currently this sets the GC system
476 to avoid expanding the heap as much as possible at the
477 expense of slowing down garbage collection a bit.
478
479 --full-aot
480 This flag instructs the Mono runtime to not generate any
481 code at runtime and depend exclusively on the code gener‐
482 ated from using mono --aot=full previously. This is use‐
483 ful for platforms that do not permit dynamic code genera‐
484 tion, or if you need to run assemblies that have been
485 stripped of IL (for example using mono-cil-strip).
486 Notice that this feature will abort execution at runtime
487 if a codepath in your program, or Mono's class libraries
488 attempts to generate code dynamically. You should test
489 your software upfront and make sure that you do not use
490 any dynamic features.
491
492 --full-aot-interp
493 Same as --full-aot with fallback to the interpreter.
494
495 --gc=boehm, --gc=sgen
496 Selects the Garbage Collector engine for Mono to use,
497 Boehm or SGen. Currently this merely ensures that you
498 are running either the mono or mono-sgen commands.
499 This flag can be set in the MONO_ENV_OPTIONS environment
500 variable to force all of your child processes to use one
501 particular kind of GC with the Mono runtime.
502
503 --gc-debug=[options]
504 Command line equivalent of the MONO_GC_DEBUG environment
505 variable.
506
507 --gc-params=[options]
508 Command line equivalent of the MONO_GC_PARAMS environment
509 variable.
510
511 --arch=32, --arch=64
512 (Mac OS X only): Selects the bitness of the Mono binary
513 used, if available. If the binary used is already for the
514 selected bitness, nothing changes. If not, the execution
515 switches to a binary with the selected bitness suffix
516 installed side by side (for example, '/bin/mono
517 --arch=64' will switch to '/bin/mono64' iff '/bin/mono'
518 is a 32-bit build).
519
520 --help, -h
521 Displays usage instructions.
522
523 --interpreter
524 The Mono runtime will use its interpreter to execute a
525 given assembly. The interpreter is usually slower than
526 the JIT, but it can be useful on platforms where code
527 generation at runtime is not allowed.
528
529 --hybrid-aot
530 This flag allows the Mono runtime to run assemblies that
531 have been stripped of IL, for example using mono-cil-
532 strip. For this to work, the assembly must have been AOT
533 compiled with --aot=hybrid.
534
535 This flag is similar to --full-aot, but it does not dis‐
536 able the JIT. This means you can use dynamic features
537 such as System.Reflection.Emit.
538
539 --llvm If the Mono runtime has been compiled with LLVM support
540 (not available in all configurations), Mono will use the
541 LLVM optimization and code generation engine to JIT or
542 AOT compile. For more information, consult:
543 http://www.mono-project.com/docs/advanced/mono-llvm/
544
545 --ffast-math
546 This flag allows Mono and LLVM to apply aggressive float‐
547 ing point optimizations. Can break IEEE754 compliance.
548
549 --nollvm
550 When using a Mono that has been compiled with LLVM sup‐
551 port, it forces Mono to fallback to its JIT engine and
552 not use the LLVM backend.
553
554 --optimize=MODE, -O=MODE
555 MODE is a comma separated list of optimizations. They
556 also allow optimizations to be turned off by prefixing
557 the optimization name with a minus sign. In general,
558 Mono has been tuned to use the default set of flags,
559 before using these flags for a deployment setting, you
560 might want to actually measure the benefits of using
561 them. The following optimization flags are implemented
562 in the core engine:
563 abcrem Array bound checks removal
564 all Turn on all optimizations
565 aot Usage of Ahead Of Time compiled code
566 branch Branch optimizations
567 cfold Constant folding
568 cmov Conditional moves [arch-dependency]
569 deadce Dead code elimination
570 consprop Constant propagation
571 copyprop Copy propagation
572 fcmov Fast x86 FP compares [arch-dependency]
573 float32 Perform 32-bit float arithmetic using 32-bit operations
574 gshared Enable generic code sharing.
575 inline Inline method calls
576 intrins Intrinsic method implementations
577 linears Linear scan global reg allocation
578 leaf Leaf procedures optimizations
579 loop Loop related optimizations
580 peephole Peephole postpass
581 precomp Precompile all methods before executing Main
582 sched Instruction scheduling
583 shared Emit per-domain code
584 sse2 SSE2 instructions on x86 [arch-dependency]
585 tailc Tail recursion and tail calls
586 For example, to enable all the optimization but dead code
587 elimination and inlining, you can use:
588 -O=all,-deadce,-inline
589 The flags that are flagged with [arch-dependency] indi‐
590 cate that the given option if used in combination with
591 Ahead of Time compilation (--aot flag) would produce pre-
592 compiled code that will depend on the current CPU and
593 might not be safely moved to another computer.
594
595 The following optimizations are supported
596
597 float32
598 Requests that the runtime performn 32-bit floating
599 point operations using only 32-bits. By default
600 the Mono runtime tries to use the highest preci‐
601 sion available for floating point operations, but
602 while this might render better results, the code
603 might run slower. This options also affects the
604 code generated by the LLVM backend.
605
606 inline Controls whether the runtime should attempt to
607 inline (the default), or not inline methods invo‐
608 cations
609 --response=FILE Provides a response file, this instructs the
610 Mono command to read other command line options from the speci‐
611 fied file, as if the options had been specified on the command
612 line. Useful when you have very long command lines.
613
614 --runtime=VERSION
615 Mono supports different runtime versions. The version
616 used depends on the program that is being run or on its
617 configuration file (named program.exe.config). This
618 option can be used to override such autodetection, by
619 forcing a different runtime version to be used. Note that
620 this should only be used to select a later compatible
621 runtime version than the one the program was compiled
622 against. A typical usage is for running a 1.1 program on
623 a 2.0 version:
624 mono --runtime=v2.0.50727 program.exe
625
626 --server
627 Configures the virtual machine to be better suited for
628 server operations (currently, allows a heavier threadpool
629 initialization).
630
631 --use-map-jit
632 Instructs Mono to generate code using MAP_JIT on MacOS.
633 Necessary for bundled applications.
634
635 --verify-all
636 Verifies mscorlib and assemblies in the global assembly
637 cache for valid IL, and all user code for IL verifiabil‐
638 ity.
639
640 This is different from --security's verifiable or validil
641 in that these options only check user code and skip
642 mscorlib and assemblies located on the global assembly
643 cache.
644
645 -V, --version
646 Prints JIT version information (system configuration,
647 release number and branch names if available).
648
649 --version=number
650 Print version number only.
651
652
653
655 The following options are used to help when developing a JITed applica‐
656 tion.
657
658 --debug, --debug=OPTIONS
659 Turns on the debugging mode in the runtime. If an assembly was
660 compiled with debugging information, it will produce line number
661 information for stack traces.
662
663 The optional OPTIONS argument is a comma separated list of
664 debugging options. These options are turned off by default
665 since they generate much larger and slower code at runtime.
666
667 The following options are supported:
668
669 casts Produces a detailed error when throwing a InvalidCastEx‐
670 ception. This option needs to be enabled as this gener‐
671 ates more verbose code at execution time.
672
673 mdb-optimizations
674 Disable some JIT optimizations which are usually only
675 disabled when running inside the debugger. This can be
676 helpful if you want to attach to the running process with
677 mdb.
678
679 gdb Generate and register debugging information with gdb.
680 This is only supported on some platforms, and only when
681 using gdb 7.0 or later.
682
683 --profile[=profiler[:profiler_args]]
684 Loads a profiler module with the given arguments. For more
685 information, see the PROFILING section. This option can be used
686 multiple times; each time will load an additional profiler mod‐
687 ule.
688
689 --trace[=expression]
690 Shows method names as they are invoked. By default all methods
691 are traced. The trace can be customized to include or exclude
692 methods, classes or assemblies. A trace expression is a comma
693 separated list of targets, each target can be prefixed with a
694 minus sign to turn off a particular target. The words `pro‐
695 gram', `all' and `disabled' have special meaning. `program'
696 refers to the main program being executed, and `all' means all
697 the method calls. The `disabled' option is used to start up
698 with tracing disabled. It can be enabled at a later point in
699 time in the program by sending the SIGUSR2 signal to the run‐
700 time. Assemblies are specified by their name, for example, to
701 trace all calls in the System assembly, use:
702
703 mono --trace=System app.exe
704
705 Classes are specified with the T: prefix. For example, to trace
706 all calls to the System.String class, use:
707
708 mono --trace=T:System.String app.exe
709
710 And individual methods are referenced with the M: prefix, and
711 the standard method notation:
712
713 mono --trace=M:System.Console:WriteLine app.exe
714
715 Exceptions can also be traced, it will cause a stack trace to be
716 printed every time an exception of the specified type is thrown.
717 The exception type can be specified with or without the names‐
718 pace, and to trace all exceptions, specify 'all' as the type
719 name.
720
721 mono --trace=E:System.Exception app.exe
722
723 As previously noted, various rules can be specified at once:
724
725 mono --trace=T:System.String,T:System.Random app.exe
726
727 You can exclude pieces, the next example traces calls to Sys‐
728 tem.String except for the System.String:Concat method.
729
730 mono --trace=T:System.String,-M:System.String:Concat
731
732 You can trace managed to unmanaged transitions using the wrapper
733 qualifier:
734
735 mono --trace=wrapper app.exe
736
737 Finally, namespaces can be specified using the N: prefix:
738
739 mono --trace=N:System.Xml
740
741
742 --no-x86-stack-align
743 Don't align stack frames on the x86 architecture. By default,
744 Mono aligns stack frames to 16 bytes on x86, so that local
745 floating point and SIMD variables can be properly aligned. This
746 option turns off the alignment, which usually saves one instruc‐
747 tion per call, but might result in significantly lower floating
748 point and SIMD performance.
749
750 --jitmap
751 Generate a JIT method map in a /tmp/perf-PID.map file. This file
752 is then used, for example, by the perf tool included in recent
753 Linux kernels. Each line in the file has:
754
755 HEXADDR HEXSIZE methodname
756
757 Currently this option is only supported on Linux.
758
760 The maintainer options are only used by those developing the runtime
761 itself, and not typically of interest to runtime users or developers.
762
763 --bisect=optimization:filename
764 This flag is used by the automatic optimization bug bisector.
765 It takes an optimization flag and a filename of a file contain‐
766 ing a list of full method names, one per line. When it compiles
767 one of the methods in the file it will use the optimization
768 given, in addition to the optimizations that are otherwise
769 enabled. Note that if the optimization is enabled by default,
770 you should disable it with `-O`, otherwise it will just apply to
771 every method, whether it's in the file or not.
772
773 --break method
774 Inserts a breakpoint before the method whose name is `method'
775 (namespace.class:methodname). Use `Main' as method name to
776 insert a breakpoint on the application's main method. You can
777 use it also with generics, for example "System.Collec‐
778 tions.Generic.Queue`1:Peek"
779
780 --breakonex
781 Inserts a breakpoint on exceptions. This allows you to debug
782 your application with a native debugger when an exception is
783 thrown.
784
785 --compile name
786 This compiles a method (namespace.name:methodname), this is used
787 for testing the compiler performance or to examine the output of
788 the code generator.
789
790 --compile-all
791 Compiles all the methods in an assembly. This is used to test
792 the compiler performance or to examine the output of the code
793 generator
794
795 --graph=TYPE METHOD
796 This generates a postscript file with a graph with the details
797 about the specified method (namespace.name:methodname). This
798 requires `dot' and ghostview to be installed (it expects Ghost‐
799 view to be called "gv"). The following graphs are available:
800 cfg Control Flow Graph (CFG)
801 dtree Dominator Tree
802 code CFG showing code
803 ssa CFG showing code after SSA translation
804 optcode CFG showing code after IR optimizations
805 Some graphs will only be available if certain optimizations are
806 turned on.
807
808 --ncompile
809 Instruct the runtime on the number of times that the method
810 specified by --compile (or all the methods if --compile-all is
811 used) to be compiled. This is used for testing the code genera‐
812 tor performance.
813
814 --stats
815 Displays information about the work done by the runtime during
816 the execution of an application.
817
818 --wapi=hps|semdel
819 Perform maintenance of the process shared data. semdel will
820 delete the global semaphore. hps will list the currently used
821 handles.
822
823 -v, --verbose
824 Increases the verbosity level, each time it is listed, increases
825 the verbosity level to include more information (including, for
826 example, a disassembly of the native code produced, code selec‐
827 tor info etc.).
828
830 The Mono runtime allows external processes to attach to a running
831 process and load assemblies into the running program. To attach to
832 the process, a special protocol is implemented in the Mono.Management
833 assembly.
834
835 With this support it is possible to load assemblies that have an entry
836 point (they are created with -target:exe or -target:winexe) to be
837 loaded and executed in the Mono process.
838
839 The code is loaded into the root domain, and it starts execution on the
840 special runtime attach thread. The attached program should create
841 its own threads and return after invocation.
842
843 This support allows for example debugging applications by having the
844 csharp shell attach to running processes.
845
847 The Mono runtime includes a profiler API that dynamically loaded pro‐
848 filer modules and embedders can use to collect performance-related data
849 about an application. Profiler modules are loaded by passing the --pro‐
850 file command line argument to the Mono runtime.
851
852 Mono ships with a few profiler modules, of which the log profiler is
853 the most feature-rich. It is also the default profiler if the profiler
854 argument is not given, or if default is given. It is possible to write
855 your own profiler modules; see the Custom profilers sub-section.
856
857 Log profiler
858 The log profiler can be used to collect a lot of information about a
859 program running in the Mono runtime. This data can be used (both while
860 the process is running and later) to do analyses of the program behav‐
861 ior, determine resource usage, performance issues or even look for par‐
862 ticular execution patterns.
863
864 This is accomplished by logging the events provided by the Mono runtime
865 through the profiler API and periodically writing them to a file which
866 can later be inspected with the mprof-report(1) tool.
867
868 More information about how to use the log profiler is available on the
869 mono-profilers(1) page, under the LOG PROFILER section, as well as the
870 mprof-report(1) page.
871
872 Coverage profiler
873 The code coverage profiler can instrument a program to help determine
874 which classes, methods, code paths, etc are actually executed. This is
875 most useful when running a test suite to determine whether the tests
876 actually cover the code they're expected to.
877
878 More information about how to use the coverage profiler is available on
879 the mono-profilers(1) page, under the COVERAGE PROFILER section.
880
881 AOT profiler
882 The AOT profiler can help improve startup performance by logging which
883 generic instantiations are used by a program, which the AOT compiler
884 can then use to compile those instantiations ahead of time so that they
885 won't have to be JIT compiled at startup.
886
887 More information about how to use the AOT profiler is available on the
888 mono-profilers(1) page, under the AOT PROFILER section.
889
890 Custom profilers
891 Custom profiler modules can be loaded in exactly the same way as the
892 standard modules that ship with Mono. They can also access the same
893 profiler API to gather all kinds of information about the code being
894 executed.
895
896 For example, to use a third-party profiler called custom, you would
897 load it like this:
898
899 mono --profile=custom program.exe
900
901 You could also pass arguments to it:
902
903 mono --profile=custom:arg1,arg2=arg3 program.exe
904
905 In the above example, Mono will load the profiler from the shared
906 library called libmono-profiler-custom.so (name varies based on plat‐
907 form, e.g., libmono-profiler-custom.dylib on OS X). This profiler mod‐
908 ule must be on your dynamic linker library path (LD_LIBRARY_PATH on
909 most systems, DYLD_LIBRARY_PATH on OS X).
910
911 For a sample of how to write your own custom profiler, look at the sam‐
912 ples/profiler/sample.c file in the Mono source tree.
913
915 To debug managed applications, you can use the mdb command, a command
916 line debugger.
917
918 It is possible to obtain a stack trace of all the active threads in
919 Mono by sending the QUIT signal to Mono, you can do this from the com‐
920 mand line, like this:
921
922 kill -QUIT pid
923
924 Where pid is the Process ID of the Mono process you want to examine.
925 The process will continue running afterwards, but its state is not
926 guaranteed.
927
928 Important: this is a last-resort mechanism for debugging applications
929 and should not be used to monitor or probe a production application.
930 The integrity of the runtime after sending this signal is not guaran‐
931 teed and the application might crash or terminate at any given point
932 afterwards.
933
934 The --debug=casts option can be used to get more detailed information
935 for Invalid Cast operations, it will provide information about the
936 types involved.
937
938 You can use the MONO_LOG_LEVEL and MONO_LOG_MASK environment variables
939 to get verbose debugging output about the execution of your application
940 within Mono.
941
942 The MONO_LOG_LEVEL environment variable if set, the logging level is
943 changed to the set value. Possible values are "error", "critical",
944 "warning", "message", "info", "debug". The default value is "error".
945 Messages with a logging level greater then or equal to the log level
946 will be printed to stdout/stderr.
947
948 Use "info" to track the dynamic loading of assemblies.
949
950 Use the MONO_LOG_MASK environment variable to limit the extent of the
951 messages you get: If set, the log mask is changed to the set value.
952 Possible values are "asm" (assembly loader), "type", "dll" (native
953 library loader), "gc" (garbage collector), "cfg" (config file loader),
954 "aot" (precompiler), "security" (e.g. Moonlight CoreCLR support),
955 "threadpool" (thread pool generic), "io-selector" (async socket opera‐
956 tions), "io-layer" (I/O layer - processes, files, sockets, events, sem‐
957 aphores, mutexes and handles), "io-layer-process", "io-layer-file",
958 "io-layer-socket", "io-layer-event", "io-layer-semaphore", "io-layer-
959 mutex", "io-layer-handle" and "all". The default value is "all".
960 Changing the mask value allows you to display only messages for a cer‐
961 tain component. You can use multiple masks by comma separating them.
962 For example to see config file messages and assembly loader messages
963 set you mask to "asm,cfg".
964
965 The following is a common use to track down problems with P/Invoke:
966
967 $ MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" mono glue.exe
968
969
971 If you are using LLDB, you can use the mono.py script to print some
972 internal data structures with it. To use this, add this to your
973 $HOME/.lldbinit file:
974 command script import $PREFIX/lib/mono/lldb/mono.py
975
976 Where $PREFIX is the prefix value that you used when you configured
977 Mono (typically /usr).
978
979 Once this is done, then you can inspect some Mono Runtime data struc‐
980 tures, for example:
981 (lldb) p method
982
983 (MonoMethod *) $0 = 0x05026ac0 [mscorlib]System.OutOfMemoryException:.ctor()
984
986 Mono's XML serialization engine by default will use a reflection-based
987 approach to serialize which might be slow for continuous processing
988 (web service applications). The serialization engine will determine
989 when a class must use a hand-tuned serializer based on a few parameters
990 and if needed it will produce a customized C# serializer for your types
991 at runtime. This customized serializer then gets dynamically loaded
992 into your application.
993
994 You can control this with the MONO_XMLSERIALIZER_THS environment vari‐
995 able.
996
997 The possible values are `no' to disable the use of a C# customized
998 serializer, or an integer that is the minimum number of uses before the
999 runtime will produce a custom serializer (0 will produce a custom seri‐
1000 alizer on the first access, 50 will produce a serializer on the 50th
1001 use). Mono will fallback to an interpreted serializer if the serializer
1002 generation somehow fails. This behavior can be disabled by setting the
1003 option `nofallback' (for example: MONO_XMLSERIALIZER_THS=0,nofallback).
1004
1006 GC_DONT_GC
1007 Turns off the garbage collection in Mono. This should be only
1008 used for debugging purposes
1009
1010 HTTP_PROXY
1011 (Also http_proxy) If set, web requests using the Mono Class
1012 Library will be automatically proxied through the given URL.
1013 Not supported on Windows, Mac OS, iOS or Android. See also
1014 NO_PROXY.
1015
1016 LLVM_COUNT
1017 When Mono is compiled with LLVM support, this instructs the run‐
1018 time to stop using LLVM after the specified number of methods
1019 are JITed. This is a tool used in diagnostics to help isolate
1020 problems in the code generation backend. For example
1021 LLVM_COUNT=10 would only compile 10 methods with LLVM and then
1022 switch to the Mono JIT engine. LLVM_COUNT=0 would disable the
1023 LLVM engine altogether.
1024
1025 MONO_ASPNET_INHIBIT_SETTINGSMAP
1026 Mono contains a feature which allows modifying settings in the
1027 .config files shipped with Mono by using config section mappers.
1028 The mappers and the mapping rules are defined in the $pre‐
1029 fix/etc/mono/2.0/settings.map file and, optionally, in the set‐
1030 tings.map file found in the top-level directory of your ASP.NET
1031 application. Both files are read by System.Web on application
1032 startup, if they are found at the above locations. If you don't
1033 want the mapping to be performed you can set this variable in
1034 your environment before starting the application and no action
1035 will be taken.
1036
1037 MONO_ASPNET_WEBCONFIG_CACHESIZE
1038 Mono has a cache of ConfigSection objects for speeding up Web‐
1039 ConfigurationManager queries. Its default size is 100 items, and
1040 when more items are needed, cache evictions start happening. If
1041 evictions are too frequent this could impose unnecessary over‐
1042 head, which could be avoided by using this environment variable
1043 to set up a higher cache size (or to lower memory requirements
1044 by decreasing it).
1045
1046 MONO_CAIRO_DEBUG_DISPOSE
1047 If set, causes Mono.Cairo to collect stack traces when objects
1048 are allocated, so that the finalization/Dispose warnings include
1049 information about the instance's origin.
1050
1051 MONO_CFG_DIR
1052 If set, this variable overrides the default system configuration
1053 directory ($PREFIX/etc). It's used to locate machine.config
1054 file.
1055
1056 MONO_COM
1057 Sets the style of COM interop. If the value of this variable is
1058 "MS" Mono will use string marhsalling routines from the
1059 liboleaut32 for the BSTR type library, any other values will use
1060 the mono-builtin BSTR string marshalling.
1061
1062 MONO_CONFIG
1063 If set, this variable overrides the default runtime configura‐
1064 tion file ($PREFIX/etc/mono/config). The --config command line
1065 options overrides the environment variable.
1066
1067 MONO_CPU_ARCH
1068 Override the automatic cpu detection mechanism. Currently used
1069 only on arm. The format of the value is as follows:
1070
1071 "armvV [thumb[2]]"
1072
1073 where V is the architecture number 4, 5, 6, 7 and the options
1074 can be currently be "thumb" or "thumb2". Example:
1075
1076 MONO_CPU_ARCH="armv4 thumb" mono ...
1077
1078
1079 MONO_ARM_FORCE_SOFT_FLOAT
1080 When Mono is built with a soft float fallback on ARM and this
1081 variable is set to "1", Mono will always emit soft float code,
1082 even if a VFP unit is detected.
1083
1084 MONO_DARWIN_USE_KQUEUE_FSW
1085 Fall back on the kqueue FileSystemWatcher implementation in Dar‐
1086 win. The default is the FSEvent implementation.
1087
1088 MONO_DARWIN_WATCHER_MAXFDS
1089 This is a debugging aid used to force limits on the kqueue
1090 FileSystemWatcher implementation in Darwin. There is no limit
1091 by default.
1092
1093 MONO_DISABLE_MANAGED_COLLATION
1094 If this environment variable is `yes', the runtime uses unman‐
1095 aged collation (which actually means no culture-sensitive colla‐
1096 tion). It internally disables managed collation functionality
1097 invoked via the members of System.Globalization.CompareInfo
1098 class. Collation is enabled by default.
1099
1100 MONO_DISABLE_SHARED_AREA
1101 Unix only: If set, disable usage of shared memory for exposing
1102 performance counters. This means it will not be possible to both
1103 externally read performance counters from this processes or read
1104 those of external processes.
1105
1106 MONO_DNS
1107 When set, enables the use of a fully managed DNS resolver
1108 instead of the regular libc functions. This resolver performs
1109 much better when multiple queries are run in parallel.
1110
1111 Note that /etc/nsswitch.conf will be ignored.
1112
1113 MONO_EGD_SOCKET
1114 For platforms that do not otherwise have a way of obtaining ran‐
1115 dom bytes this can be set to the name of a file system socket on
1116 which an egd or prngd daemon is listening.
1117
1118 MONO_ENABLE_AIO
1119 If set, tells mono to attempt using native asynchronous I/O ser‐
1120 vices. If not set, a default select/poll implementation is used.
1121 Currently epoll and kqueue are supported.
1122
1123 MONO_THREADS_SUSPEND Selects a mechanism that Mono will use to suspend
1124 threads. May be set to "preemptive", "coop", or "hybrid".
1125 Threads may need to be suspended by the debugger, or using some
1126 .NET threading APIs, and most commonly when the SGen garbage
1127 collector needs to stop all threads during a critical phase of
1128 garbage collection. Preemptive mode is the mode that Mono has
1129 used historically, going back to the Boehm days, where the
1130 garbage collector would run at any point and suspend execution
1131 of all threads as required to perform a garbage collection. The
1132 cooperative mode on the other hand requires the cooperation of
1133 all threads to stop at a safe point. This makes for an easier
1134 to debug garbage collector and it improves the stability of the
1135 runtime because threads are not suspended when accessing criti‐
1136 cal resources. In scenarios where Mono is embedded in another
1137 application, cooperative suspend requires the embedder code to
1138 follow coding guidelines in order to cooperate with the garbage
1139 collector. Cooperative suspend in embedded Mono is currently
1140 experimental. Hybrid mode is a combination of the two that
1141 retains better compatability with scenarios where Mono is embed‐
1142 ded in another application: threads that are running managed
1143 code or code that comprises the Mono runtime will be coopera‐
1144 tively suspended, while threads running embedder code will be
1145 preemptively suspended. Hybrid suspend is the default on some
1146 desktop platforms.
1147
1148 Alternatively, coop and hybrid mode can be enabled at compile
1149 time by using the --enable-cooperative-suspend or --enable-
1150 hybrid-suspend flags, respectively, when calling configure. The
1151 MONO_THREADS_SUSPEND environment variable takes priority over
1152 the compiled default.
1153
1154 MONO_ENABLE_COOP_SUSPEND
1155 This environment variable is obsolete, but retained for backward
1156 compatibility. Use MONO_THREADS_SUSPEND set to "coop" instead.
1157 Note that if configure flags were provided to enable cooperative
1158 or hybrid suspend, this variable is ignored.
1159
1160 MONO_ENV_OPTIONS
1161 This environment variable allows you to pass command line argu‐
1162 ments to a Mono process through the environment. This is use‐
1163 ful for example to force all of your Mono processes to use LLVM
1164 or SGEN without having to modify any launch scripts.
1165
1166 MONO_SDB_ENV_OPTIONS
1167 Used to pass extra options to the debugger agent in the runtime,
1168 as they were passed using --debugger-agent=.
1169
1170 MONO_EVENTLOG_TYPE
1171 Sets the type of event log provider to use (for System.Diagnos‐
1172 tics.EventLog). Possible values are:
1173
1174 local[:path]
1175 Persists event logs and entries to the local file system.
1176 The directory in which to persist the event logs, event
1177 sources and entries can be specified as part of the
1178 value. If the path is not explicitly set, it defaults to
1179 "/var/lib/mono/eventlog" on unix and "%APPDATA%no\vent‐
1180 log" on Windows.
1181
1182 win32 Uses the native win32 API to write events and registers
1183 event logs and event sources in the registry. This is
1184 only available on Windows. On Unix, the directory per‐
1185 mission for individual event log and event source direc‐
1186 tories is set to 777 (with +t bit) allowing everyone to
1187 read and write event log entries while only allowing
1188 entries to be deleted by the user(s) that created them.
1189
1190 null Silently discards any events.
1191
1192 The default is "null" on Unix (and versions of Windows before
1193 NT), and "win32" on Windows NT (and higher).
1194
1195 MONO_EXTERNAL_ENCODINGS
1196 If set, contains a colon-separated list of text encodings to try
1197 when turning externally-generated text (e.g. command-line argu‐
1198 ments or filenames) into Unicode. The encoding names come from
1199 the list provided by iconv, and the special case
1200 "default_locale" which refers to the current locale's default
1201 encoding.
1202
1203 When reading externally-generated text strings UTF-8 is tried
1204 first, and then this list is tried in order with the first suc‐
1205 cessful conversion ending the search. When writing external
1206 text (e.g. new filenames or arguments to new processes) the
1207 first item in this list is used, or UTF-8 if the environment
1208 variable is not set.
1209
1210 The problem with using MONO_EXTERNAL_ENCODINGS to process your
1211 files is that it results in a problem: although its possible to
1212 get the right file name it is not necessarily possible to open
1213 the file. In general if you have problems with encodings in
1214 your filenames you should use the "convmv" program.
1215
1216 MONO_GC_PARAMS
1217 When using Mono with the SGen garbage collector this variable
1218 controls several parameters of the collector. The variable's
1219 value is a comma separated list of words.
1220
1221 max-heap-size=size
1222 Sets the maximum size of the heap. The size is specified
1223 in bytes and must be a power of two. The suffixes `k',
1224 `m' and `g' can be used to specify kilo-, mega- and giga‐
1225 bytes, respectively. The limit is the sum of the nursery,
1226 major heap and large object heap. Once the limit is
1227 reached the application will receive OutOfMemoryExcep‐
1228 tions when trying to allocate. Not the full extent of
1229 memory set in max-heap-size could be available to satisfy
1230 a single allocation due to internal fragmentation. By
1231 default heap limits is disabled and the GC will try to
1232 use all available memory.
1233
1234 nursery-size=size
1235 Sets the size of the nursery. The size is specified in
1236 bytes and must be a power of two. The suffixes `k', `m'
1237 and `g' can be used to specify kilo-, mega- and giga‐
1238 bytes, respectively. The nursery is the first generation
1239 (of two). A larger nursery will usually speed up the
1240 program but will obviously use more memory. The default
1241 nursery size 4 MB.
1242
1243 major=collector
1244 Specifies which major collector to use. Options are
1245 `marksweep' for the Mark&Sweep collector, `marksweep-
1246 conc' for concurrent Mark&Sweep and `marksweep-conc-par'
1247 for parallel and concurrent Mark&Sweep. The concurrent
1248 Mark&Sweep collector is the default.
1249
1250 mode=balanced|throughput|pause[:max-pause]
1251 Specifies what should be the garbage collector's target.
1252 The `throughput' mode aims to reduce time spent in the
1253 garbage collector and improve application speed, the
1254 `pause' mode aims to keep pause times to a minimum and it
1255 receives the argument max-pause which specifies the maxi‐
1256 mum pause time in milliseconds that is acceptable and the
1257 `balanced' mode which is a general purpose optimal mode.
1258
1259 soft-heap-limit=size
1260 Once the heap size gets larger than this size, ignore
1261 what the default major collection trigger metric says and
1262 only allow four nursery size's of major heap growth
1263 between major collections.
1264
1265 evacuation-threshold=threshold
1266 Sets the evacuation threshold in percent. This option is
1267 only available on the Mark&Sweep major collectors. The
1268 value must be an integer in the range 0 to 100. The
1269 default is 66. If the sweep phase of the collection
1270 finds that the occupancy of a specific heap block type is
1271 less than this percentage, it will do a copying collec‐
1272 tion for that block type in the next major collection,
1273 thereby restoring occupancy to close to 100 percent. A
1274 value of 0 turns evacuation off.
1275
1276 (no-)lazy-sweep
1277 Enables or disables lazy sweep for the Mark&Sweep collec‐
1278 tor. If enabled, the sweeping of individual major heap
1279 blocks is done piecemeal whenever the need arises, typi‐
1280 cally during nursery collections. Lazy sweeping is
1281 enabled by default.
1282
1283 (no-)concurrent-sweep
1284 Enables or disables concurrent sweep for the Mark&Sweep
1285 collector. If enabled, the iteration of all major blocks
1286 to determine which ones can be freed and which ones have
1287 to be kept and swept, is done concurrently with the run‐
1288 ning program. Concurrent sweeping is enabled by default.
1289
1290 stack-mark=mark-mode
1291 Specifies how application threads should be scanned.
1292 Options are `precise` and `conservative`. Precise marking
1293 allow the collector to know what values on stack are ref‐
1294 erences and what are not. Conservative marking threats
1295 all values as potentially references and leave them
1296 untouched. Precise marking reduces floating garbage and
1297 can speed up nursery collection and allocation rate, it
1298 has the downside of requiring a significant extra memory
1299 per compiled method. The right option, unfortunately,
1300 requires experimentation.
1301
1302 save-target-ratio=ratio
1303 Specifies the target save ratio for the major collector.
1304 The collector lets a given amount of memory to be pro‐
1305 moted from the nursery due to minor collections before it
1306 triggers a major collection. This amount is based on how
1307 much memory it expects to free. It is represented as a
1308 ratio of the size of the heap after a major collection.
1309 Valid values are between 0.1 and 2.0. The default is 0.5.
1310 Smaller values will keep the major heap size smaller but
1311 will trigger more major collections. Likewise, bigger
1312 values will use more memory and result in less frequent
1313 major collections. This option is EXPERIMENTAL, so it
1314 might disappear in later versions of mono.
1315
1316 default-allowance-ratio=ratio
1317 Specifies the default allocation allowance when the cal‐
1318 culated size is too small. The allocation allowance is
1319 how much memory the collector let be promoted before
1320 triggered a major collection. It is a ratio of the nurs‐
1321 ery size. Valid values are between 1.0 and 10.0. The
1322 default is 4.0. Smaller values lead to smaller heaps and
1323 more frequent major collections. Likewise, bigger values
1324 will allow the heap to grow faster but use more memory
1325 when it reaches a stable size. This option is EXPERIMEN‐
1326 TAL, so it might disappear in later versions of mono.
1327
1328 minor=minor-collector
1329 Specifies which minor collector to use. Options are `sim‐
1330 ple' which promotes all objects from the nursery directly
1331 to the old generation, `simple-par' which has same promo‐
1332 tion behavior as `simple' but using multiple workers and
1333 `split' which lets objects stay longer on the nursery
1334 before promoting.
1335
1336 alloc-ratio=ratio
1337 Specifies the ratio of memory from the nursery to be use
1338 by the alloc space. This only can only be used with the
1339 split minor collector. Valid values are integers between
1340 1 and 100. Default is 60.
1341
1342 promotion-age=age
1343 Specifies the required age of an object must reach inside
1344 the nursery before been promoted to the old generation.
1345 This only can only be used with the split minor collec‐
1346 tor. Valid values are integers between 1 and 14. Default
1347 is 2.
1348
1349 (no-)cementing
1350 Enables or disables cementing. This can dramatically
1351 shorten nursery collection times on some benchmarks where
1352 pinned objects are referred to from the major heap.
1353
1354 allow-synchronous-major
1355 This forbids the major collector from performing synchro‐
1356 nous major collections. The major collector might want
1357 to do a synchronous collection due to excessive fragmen‐
1358 tation. Disabling this might trigger OutOfMemory error in
1359 situations that would otherwise not happen.
1360
1361 MONO_GC_DEBUG
1362 When using Mono with the SGen garbage collector this environment
1363 variable can be used to turn on various debugging features of
1364 the collector. The value of this variable is a comma separated
1365 list of words. Do not use these options in production.
1366
1367 number Sets the debug level to the specified number.
1368
1369 print-allowance
1370 After each major collection prints memory consumption for
1371 before and after the collection and the allowance for the
1372 minor collector, i.e. how much the heap is allowed to
1373 grow from minor collections before the next major collec‐
1374 tion is triggered.
1375
1376 print-pinning
1377 Gathers statistics on the classes whose objects are
1378 pinned in the nursery and for which global remset entries
1379 are added. Prints those statistics when shutting down.
1380
1381 collect-before-allocs
1382
1383 check-remset-consistency
1384 This performs a remset consistency check at various
1385 opportunities, and also clears the nursery at collection
1386 time, instead of the default, when buffers are allocated
1387 (clear-at-gc). The consistency check ensures that there
1388 are no major to minor references that are not on the
1389 remembered sets.
1390
1391 mod-union-consistency-check
1392 Checks that the mod-union cardtable is consistent before
1393 each finishing major collection pause. This check is
1394 only applicable to concurrent major collectors.
1395
1396 check-mark-bits
1397 Checks that mark bits in the major heap are consistent at
1398 the end of each major collection. Consistent mark bits
1399 mean that if an object is marked, all objects that it had
1400 references to must also be marked.
1401
1402 check-nursery-untag
1403 After garbage collections, check whether all vtable
1404 pointers are no longer tagged.
1405
1406 xdomain-checks
1407 Performs a check to make sure that no references are left
1408 to an unloaded AppDomain.
1409
1410 clear-at-tlab-creation
1411 Clears the nursery incrementally when the thread local
1412 allocation buffers (TLAB) are created. The default set‐
1413 ting clears the whole nursery at GC time.
1414
1415 debug-clear-at-tlab-creation
1416 Clears the nursery incrementally when the thread local
1417 allocation buffers (TLAB) are created, but at GC time
1418 fills it with the byte `0xff`, which should result in a
1419 crash more quickly if `clear-at-tlab-creation` doesn't
1420 work properly.
1421
1422 clear-at-gc
1423 This clears the nursery at GC time instead of doing it
1424 when the thread local allocation buffer (TLAB) is cre‐
1425 ated. The default is to clear the nursery at TLAB cre‐
1426 ation time.
1427
1428 disable-minor
1429 Don't do minor collections. If the nursery is full, a
1430 major collection is triggered instead, unless it, too, is
1431 disabled.
1432
1433 disable-major
1434 Don't do major collections.
1435
1436 conservative-stack-mark
1437 Forces the GC to scan the stack conservatively, even if
1438 precise scanning is available.
1439
1440 no-managed-allocator
1441 Disables the managed allocator.
1442
1443 check-scan-starts
1444 If set, does a plausibility check on the scan_starts
1445 before and after each collection
1446
1447 verify-nursery-at-minor-gc
1448 If set, does a complete object walk of the nursery at the
1449 start of each minor collection.
1450
1451 dump-nursery-at-minor-gc
1452 If set, dumps the contents of the nursery at the start of
1453 each minor collection. Requires verify-nursery-at-minor-
1454 gc to be set.
1455
1456 heap-dump=file
1457 Dumps the heap contents to the specified file. To visu‐
1458 alize the information, use the mono-heapviz tool.
1459
1460 binary-protocol=file
1461 Outputs the debugging output to the specified file. For
1462 this to work, Mono needs to be compiled with the
1463 BINARY_PROTOCOL define on sgen-gc.c. You can then use
1464 this command to explore the output
1465 sgen-grep-binprot 0x1234 0x5678 < file
1466
1467 nursery-canaries
1468 If set, objects allocated in the nursery are suffixed
1469 with a canary (guard) word, which is checked on each
1470 minor collection. Can be used to detect/debug heap cor‐
1471 ruption issues.
1472
1473
1474 do-not-finalize(=classes)
1475 If enabled, finalizers will not be run. Everything else
1476 will be unaffected: finalizable objects will still be put
1477 into the finalization queue where they survive until
1478 they're scheduled to finalize. Once they're not in the
1479 queue anymore they will be collected regularly. If a
1480 list of comma-separated class names is given, only
1481 objects from those classes will not be finalized.
1482
1483
1484 log-finalizers
1485 Log verbosely around the finalization process to aid
1486 debugging.
1487
1488 MONO_GAC_PREFIX
1489 Provides a prefix the runtime uses to look for Global Assembly
1490 Caches. Directories are separated by the platform path separa‐
1491 tor (colons on unix). MONO_GAC_PREFIX should point to the top
1492 directory of a prefixed install. Or to the directory provided in
1493 the gacutil /gacdir command. Example: /home/user‐
1494 name/.mono:/usr/local/mono/
1495
1496 MONO_IOMAP
1497 Enables some filename rewriting support to assist badly-written
1498 applications that hard-code Windows paths. Set to a colon-sepa‐
1499 rated list of "drive" to strip drive letters, or "case" to do
1500 case-insensitive file matching in every directory in a path.
1501 "all" enables all rewriting methods. (Backslashes are always
1502 mapped to slashes if this variable is set to a valid option).
1503 For example, this would work from the shell:
1504
1505 MONO_IOMAP=drive:case
1506 export MONO_IOMAP
1507
1508 If you are using mod_mono to host your web applications, you can
1509 use the MonoIOMAP directive instead, like this:
1510
1511 MonoIOMAP <appalias> all
1512
1513 See mod_mono(8) for more details.
1514
1515 MONO_LLVM
1516 When Mono is using the LLVM code generation backend you can use
1517 this environment variable to pass code generation options to the
1518 LLVM compiler.
1519
1520 MONO_MANAGED_WATCHER
1521 If set to "disabled", System.IO.FileSystemWatcher will use a
1522 file watcher implementation which silently ignores all the
1523 watching requests. If set to any other value, Sys‐
1524 tem.IO.FileSystemWatcher will use the default managed implemen‐
1525 tation (slow). If unset, mono will try to use inotify, FAM,
1526 Gamin, kevent under Unix systems and native API calls on Win‐
1527 dows, falling back to the managed implementation on error.
1528
1529 MONO_MESSAGING_PROVIDER
1530 Mono supports a plugin model for its implementation of Sys‐
1531 tem.Messaging making it possible to support a variety of messag‐
1532 ing implementations (e.g. AMQP, ActiveMQ). To specify which
1533 messaging implementation is to be used the evironement variable
1534 needs to be set to the full class name for the provider. E.g.
1535 to use the RabbitMQ based AMQP implementation the variable
1536 should be set to:
1537
1538 Mono.Messaging.RabbitMQ.RabbitMQMessagingProvider,Mono.Messaging.RabbitMQ
1539
1540 MONO_NO_SMP
1541 If set causes the mono process to be bound to a single processor. This may be
1542 useful when debugging or working around race conditions.
1543
1544 MONO_NO_TLS
1545 Disable inlining of thread local accesses. Try setting this if you get a segfault
1546 early on in the execution of mono.
1547
1548 MONO_PATH
1549 Provides a search path to the runtime where to look for library
1550 files. This is a tool convenient for debugging applications, but
1551 should not be used by deployed applications as it breaks the assembly
1552 loader in subtle ways.
1553 Directories are separated by the platform path separator (colons on unix). Example:
1554 /home/username/lib:/usr/local/mono/lib
1555 Relative paths are resolved based on the launch-time current directory.
1556 Alternative solutions to MONO_PATH include: installing libraries into
1557 the Global Assembly Cache (see gacutil(1)) or having the dependent
1558 libraries side-by-side with the main executable.
1559 For a complete description of recommended practices for application
1560 deployment, see
1561 http://www.mono-project.com/docs/getting-started/application-deployment/
1562
1563 MONO_SHARED_DIR
1564 If set its the directory where the ".wapi" handle state is stored.
1565 This is the directory where the Windows I/O Emulation layer stores its
1566 shared state data (files, events, mutexes, pipes). By default Mono
1567 will store the ".wapi" directory in the users's home directory.
1568
1569 MONO_SHARED_HOSTNAME
1570 Uses the string value of this variable as a replacement for the host name when
1571 creating file names in the ".wapi" directory. This helps if the host name of
1572 your machine is likely to be changed when a mono application is running or if
1573 you have a .wapi directory shared among several different computers.
1574 Mono typically uses the hostname to create the files that are used to
1575 share state across multiple Mono processes. This is done to support
1576 home directories that might be shared over the network.
1577
1578 MONO_STRICT_IO_EMULATION
1579 If set, extra checks are made during IO operations. Currently, this
1580 includes only advisory locks around file writes.
1581
1582 MONO_TLS_PROVIDER
1583 This environment variable controls which TLS/SSL provider Mono will
1584 use. The options are usually determined by the operating system where
1585 Mono was compiled and the configuration options that were used for
1586 it.
1587
1588 default
1589 Uses the default TLS stack that the Mono runtime was configured with.
1590 Usually this is configured to use Apple's SSL stack on Apple
1591 platforms, and Boring SSL on other platforms.
1592
1593 apple Forces the use of the Apple SSL stack, only works on Apple platforms.
1594
1595 btls Forces the use of the BoringSSL stack. See
1596 https://opensource.google.com/projects/boringssl for more information
1597 about this stack.
1598
1599 legacy This is the old Mono stack, which only supports SSL and TLS up to
1600 version 1.0. It is deprecated and will be removed in the future.
1601
1602 MONO_TLS_SESSION_CACHE_TIMEOUT
1603 The time, in seconds, that the SSL/TLS session cache will keep it's entry to
1604 avoid a new negotiation between the client and a server. Negotiation are very
1605 CPU intensive so an application-specific custom value may prove useful for
1606 small embedded systems.
1607 The default is 180 seconds.
1608
1609 MONO_THREADS_PER_CPU
1610 The minimum number of threads in the general threadpool will be
1611 MONO_THREADS_PER_CPU * number of CPUs. The default value for this
1612 variable is 1.
1613
1614 MONO_XMLSERIALIZER_THS
1615 Controls the threshold for the XmlSerializer to produce a custom
1616 serializer for a given class instead of using the Reflection-based
1617 interpreter. The possible values are `no' to disable the use of a
1618 custom serializer or a number to indicate when the XmlSerializer
1619 should start serializing. The default value is 50, which means that
1620 the a custom serializer will be produced on the 50th use.
1621
1622 MONO_X509_REVOCATION_MODE
1623 Sets the revocation mode used when validating a X509 certificate chain (https,
1624 ftps, smtps...). The default is 'nocheck', which performs no revocation check
1625 at all. The other possible values are 'offline', which performs CRL check (not
1626 implemented yet) and 'online' which uses OCSP and CRL to verify the revocation
1627 status (not implemented yet).
1628
1629 NO_PROXY
1630 (Also no_proxy) If both HTTP_PROXY and NO_PROXY are
1631 set, NO_PROXY will be treated as a comma-separated list of "bypass" domains
1632 which will not be sent through the proxy. Domains in NO_PROXY may contain
1633 wildcards, as in "*.mono-project.com" or "build????.local". Not supported on
1634 Windows, Mac OS, iOS or Android.
1635
1637 MONO_ASPNET_NODELETE
1638 If set to any value, temporary source files generated by ASP.NET
1639 support classes will not be removed. They will be kept in the
1640 user's temporary directory.
1641
1642 MONO_DEBUG
1643 If set, enables some features of the runtime useful for debug‐
1644 ging. This variable should contain a comma separated list of
1645 debugging options. Currently, the following options are sup‐
1646 ported:
1647
1648 align-small-structs
1649 Enables small structs alignment to 4/8 bytes.
1650
1651 arm-use-fallback-tls
1652 When this option is set on ARM, a fallback thread local
1653 store will be used instead of the default fast thread
1654 local storage primitives.
1655
1656 break-on-unverified
1657 If this variable is set, when the Mono VM runs into a
1658 verification problem, instead of throwing an exception it
1659 will break into the debugger. This is useful when debug‐
1660 ging verifier problems
1661
1662 casts This option can be used to get more detailed information
1663 from InvalidCast exceptions, it will provide information
1664 about the types involved.
1665
1666 check-pinvoke-callconv
1667 This option causes the runtime to check for calling con‐
1668 vention mismatches when using pinvoke, i.e. mixing
1669 cdecl/stdcall. It only works on windows. If a mismatch is
1670 detected, an ExecutionEngineException is thrown.
1671
1672 collect-pagefault-stats
1673 Collects information about pagefaults. This is used
1674 internally to track the number of page faults produced to
1675 load metadata. To display this information you must use
1676 this option with "--stats" command line option.
1677
1678 debug-domain-unload
1679 When this option is set, the runtime will invalidate the
1680 domain memory pool instead of destroying it.
1681
1682 disable_omit_fp
1683 Disables a compiler optimization where the frame pointer
1684 is omitted from the stack. This optimization can interact
1685 badly with debuggers.
1686
1687 dont-free-domains
1688 This is an Optimization for multi-AppDomain applications
1689 (most commonly ASP.NET applications). Due to internal
1690 limitations Mono, Mono by default does not use typed
1691 allocations on multi-appDomain applications as they could
1692 leak memory when a domain is unloaded. Although this is
1693 a fine default, for applications that use more than on
1694 AppDomain heavily (for example, ASP.NET applications) it
1695 is worth trading off the small leaks for the increased
1696 performance (additionally, since ASP.NET applications are
1697 not likely going to unload the application domains on
1698 production systems, it is worth using this feature).
1699
1700 dyn-runtime-invoke
1701 Instructs the runtime to try to use a generic runtime-
1702 invoke wrapper instead of creating one invoke wrapper.
1703
1704 explicit-null-checks
1705 Makes the JIT generate an explicit NULL check on variable
1706 dereferences instead of depending on the operating system
1707 to raise a SIGSEGV or another form of trap event when an
1708 invalid memory location is accessed.
1709
1710 gdb Equivalent to setting the MONO_XDEBUG variable, this
1711 emits symbols into a shared library as the code is JITed
1712 that can be loaded into GDB to inspect symbols.
1713
1714 gen-seq-points
1715 Automatically generates sequence points where the IL
1716 stack is empty. These are places where the debugger can
1717 set a breakpoint.
1718
1719 no-compact-seq-points
1720 Unless the option is used, the runtime generates sequence
1721 points data that maps native offsets to IL offsets.
1722 Sequence point data is used to display IL offset in
1723 stacktraces. Stacktraces with IL offsets can be symboli‐
1724 cated using mono-symbolicate tool.
1725
1726 handle-sigint
1727 Captures the interrupt signal (Control-C) and displays a
1728 stack trace when pressed. Useful to find out where the
1729 program is executing at a given point. This only dis‐
1730 plays the stack trace of a single thread.
1731
1732 init-stacks
1733 Instructs the runtime to initialize the stack with some
1734 known values (0x2a on x86-64) at the start of a method to
1735 assist in debuggin the JIT engine.
1736
1737 keep-delegates
1738 This option will leak delegate trampolines that are no
1739 longer referenced as to present the user with more infor‐
1740 mation about a delegate misuse. Basically a delegate
1741 instance might be created, passed to unmanaged code, and
1742 no references kept in managed code, which will garbage
1743 collect the code. With this option it is possible to
1744 track down the source of the problems.
1745
1746 no-gdb-backtrace
1747 This option will disable the GDB backtrace emitted by the
1748 runtime after a SIGSEGV or SIGABRT in unmanaged code.
1749
1750 partial-sharing
1751 When this option is set, the runtime can share generated
1752 code between generic types effectively reducing the
1753 amount of code generated.
1754
1755 reverse-pinvoke-exceptions
1756 This option will cause mono to abort with a descriptive
1757 message when during stack unwinding after an exception it
1758 reaches a native stack frame. This happens when a managed
1759 delegate is passed to native code, and the managed dele‐
1760 gate throws an exception. Mono will normally try to
1761 unwind the stack to the first (managed) exception han‐
1762 dler, and it will skip any native stack frames in the
1763 process. This leads to undefined behaviour (since mono
1764 doesn't know how to process native frames), leaks, and
1765 possibly crashes too.
1766
1767 single-imm-size
1768 This guarantees that each time managed code is compiled
1769 the same instructions and registers are used, regardless
1770 of the size of used values.
1771
1772 soft-breakpoints
1773 This option allows using single-steps and breakpoints in
1774 hardware where we cannot do it with signals.
1775
1776 suspend-on-native-crash
1777 This option will suspend the program when a native crash
1778 occurs (SIGSEGV, SIGILL, ...). This is useful for debug‐
1779 ging crashes which do not happen under gdb, since a live
1780 process contains more information than a core file.
1781
1782 suspend-on-sigsegv
1783 Same as suspend-on-native-crash.
1784
1785 suspend-on-exception
1786 This option will suspend the program when an exception
1787 occurs.
1788
1789 suspend-on-unhandled
1790 This option will suspend the program when an unhandled
1791 exception occurs.
1792
1793 thread-dump-dir=DIR
1794 Use DIR for storage thread dumps created by SIGQUIT.
1795
1796 weak-memory-model
1797 Don't enforce the CLR memory model on platforms with weak
1798 memory models. This can introduce random crashes in some
1799 rare cases, for multithreaded environments. This can be
1800 used for a performance boost on applications that are
1801 single threaded.
1802
1803 verbose-gdb
1804 Make gdb output on native crashes more verbose.
1805
1806 MONO_LOG_LEVEL
1807 The logging level, possible values are `error', `critical',
1808 `warning', `message', `info' and `debug'. See the DEBUGGING
1809 section for more details.
1810
1811 MONO_LOG_MASK
1812 Controls the domain of the Mono runtime that logging will apply
1813 to. If set, the log mask is changed to the set value. Possible
1814 values are "asm" (assembly loader), "type", "dll" (native
1815 library loader), "gc" (garbage collector), "cfg" (config file
1816 loader), "aot" (precompiler), "security" (e.g. Moonlight CoreCLR
1817 support) and "all". The default value is "all". Changing the
1818 mask value allows you to display only messages for a certain
1819 component. You can use multiple masks by comma separating them.
1820 For example to see config file messages and assembly loader mes‐
1821 sages set you mask to "asm,cfg".
1822
1823 MONO_LOG_DEST
1824 Controls where trace log messages are written. If not set then
1825 the messages go to stdout. If set, the string either specifies
1826 a path to a file that will have messages appended to it, or the
1827 string "syslog" in which case the messages will be written to
1828 the system log. Under Windows, this is simulated by writing to
1829 a file called "mono.log". MONO_LOG_HEADER Controls whether
1830 trace log messages not directed to syslog have the id, time‐
1831 stamp, and pid as the prefix to the log message. To enable a
1832 header this environment variable need just be non-null.
1833
1834 MONO_TRACE
1835 Used for runtime tracing of method calls. The format of the
1836 comma separated trace options is:
1837
1838 [-]M:method name
1839 [-]N:namespace
1840 [-]T:class name
1841 [-]all
1842 [-]program
1843 disabled Trace output off upon start.
1844
1845 You can toggle trace output on/off sending a SIGUSR2 signal to
1846 the program.
1847
1848 MONO_TRACE_LISTENER
1849 If set, enables the System.Diagnostics.DefaultTraceListener,
1850 which will print the output of the System.Diagnostics Trace and
1851 Debug classes. It can be set to a filename, and to Console.Out
1852 or Console.Error to display output to standard output or stan‐
1853 dard error, respectively. If it's set to Console.Out or Con‐
1854 sole.Error you can append an optional prefix that will be used
1855 when writing messages like this: Console.Error:MyProgramName.
1856 See the System.Diagnostics.DefaultTraceListener documentation
1857 for more information.
1858
1859 MONO_WCF_TRACE
1860 This eases WCF diagnostics functionality by simply outputs all
1861 log messages from WCF engine to "stdout", "stderr" or any file
1862 passed to this environment variable. The log format is the same
1863 as usual diagnostic output.
1864
1865 MONO_XEXCEPTIONS
1866 This throws an exception when a X11 error is encountered; by
1867 default a message is displayed but execution continues
1868
1869 MONO_XMLSERIALIZER_DEBUG
1870 Set this value to 1 to prevent the serializer from removing the
1871 temporary files that are created for fast serialization; This
1872 might be useful when debugging.
1873
1874 MONO_XSYNC
1875 This is used in the System.Windows.Forms implementation when
1876 running with the X11 backend. This is used to debug problems in
1877 Windows.Forms as it forces all of the commands send to X11
1878 server to be done synchronously. The default mode of operation
1879 is asynchronous which makes it hard to isolate the root of cer‐
1880 tain problems.
1881
1882 MONO_XDEBUG
1883 When the the MONO_XDEBUG env var is set, debugging info for JIT‐
1884 ted code is emitted into a shared library, loadable into gdb.
1885 This enables, for example, to see managed frame names on gdb
1886 backtraces.
1887
1888 MONO_VERBOSE_METHOD
1889 Enables the maximum JIT verbosity for the specified method. This
1890 is very helpfull to diagnose a miscompilation problems of a spe‐
1891 cific method. This can be a semicolon-separated list of method
1892 names to match. If the name is simple, this applies to any
1893 method with that name, otherwise you can use a mono method
1894 description (see the section METHOD DESCRIPTIONS).
1895
1896 MONO_JIT_DUMP_METHOD
1897 Enables sending of the JITs intermediate representation for a
1898 specified method to the IdealGraphVisualizer tool.
1899
1900 MONO_VERBOSE_HWCAP
1901 If set, makes the JIT output information about detected CPU fea‐
1902 tures (such as SSE, CMOV, FCMOV, etc) to stdout.
1903
1904 MONO_CONSERVATIVE_HWCAP
1905 If set, the JIT will not perform any hardware capability detec‐
1906 tion. This may be useful to pinpoint the cause of JIT issues.
1907 This is the default when Mono is built as an AOT cross compiler,
1908 so that the generated code will run on most hardware.
1909
1911 If you want to use Valgrind, you will find the file `mono.supp' useful,
1912 it contains the suppressions for the GC which trigger incorrect warn‐
1913 ings. Use it like this:
1914 valgrind --suppressions=mono.supp mono ...
1915
1917 On some platforms, Mono can expose a set of DTrace probes (also known
1918 as user-land statically defined, USDT Probes).
1919
1920 They are defined in the file `mono.d'.
1921
1922 ves-init-begin, ves-init-end
1923 Begin and end of runtime initialization.
1924
1925 method-compile-begin, method-compile-end
1926 Begin and end of method compilation. The probe arguments are
1927 class name, method name and signature, and in case of method-
1928 compile-end success or failure of compilation.
1929
1930 gc-begin, gc-end
1931 Begin and end of Garbage Collection.
1932
1933 To verify the availability of the probes, run:
1934 dtrace -P mono'$target' -l -c mono
1935
1937 Mono's Ping implementation for detecting network reachability can cre‐
1938 ate the ICMP packets itself without requiring the system ping command
1939 to do the work. If you want to enable this on Linux for non-root
1940 users, you need to give the Mono binary special permissions.
1941
1942 As root, run this command:
1943 # setcap cap_net_raw=+ep /usr/bin/mono
1944
1946 On Unix assemblies are loaded from the installation lib directory. If
1947 you set `prefix' to /usr, the assemblies will be located in /usr/lib.
1948 On Windows, the assemblies are loaded from the directory where mono and
1949 mint live.
1950
1951 ~/.mono/aot-cache
1952 The directory for the ahead-of-time compiler demand creation
1953 assemblies are located.
1954
1955 /etc/mono/config, ~/.mono/config
1956 Mono runtime configuration file. See the mono-config(5) manual
1957 page for more information.
1958
1959 ~/.config/.mono/certs, /usr/share/.mono/certs
1960 Contains Mono certificate stores for users / machine. See the
1961 certmgr(1) manual page for more information on managing certifi‐
1962 cate stores and the mozroots(1) page for information on how to
1963 import the Mozilla root certificates into the Mono certificate
1964 store.
1965
1966 ~/.mono/assemblies/ASSEMBLY/ASSEMBLY.config
1967 Files in this directory allow a user to customize the configura‐
1968 tion for a given system assembly, the format is the one
1969 described in the mono-config(5) page.
1970
1971 ~/.config/.mono/keypairs, /usr/share/.mono/keypairs
1972 Contains Mono cryptographic keypairs for users / machine. They
1973 can be accessed by using a CspParameters object with DSACryp‐
1974 toServiceProvider and RSACryptoServiceProvider classes.
1975
1976 ~/.config/.isolatedstorage, ~/.local/share/.isolatedstorage,
1977 /usr/share/.isolatedstorage
1978 Contains Mono isolated storage for non-roaming users, roaming
1979 users and local machine. Isolated storage can be accessed using
1980 the classes from the System.IO.IsolatedStorage namespace.
1981
1982 <assembly>.config
1983 Configuration information for individual assemblies is loaded by
1984 the runtime from side-by-side files with the .config files, see
1985 the http://www.mono-project.com/Config for more information.
1986
1987 Web.config, web.config
1988 ASP.NET applications are configured through these files, the
1989 configuration is done on a per-directory basis. For more infor‐
1990 mation on this subject see the http://www.mono-project.com/Con‐
1991 fig_system.web page.
1992
1994 Mailing lists are listed at the http://www.mono-project.com/commu‐
1995 nity/help/mailing-lists/
1996
1998 http://www.mono-project.com
1999
2001 certmgr(1), cert-sync(1), csharp(1), gacutil(1), mcs(1), monodis(1),
2002 mono-config(5), mono-profilers(1), mprof-report(1), pdb2mdb(1), xsp(1),
2003 mod_mono(8)
2004
2005 For more information on AOT: http://www.mono-
2006 project.com/docs/advanced/aot/
2007
2008 For ASP.NET-related documentation, see the xsp(1) manual page
2009
2010
2011
2012 Mono(mono)