1Mono(Mono 1.0) Mono(Mono 1.0)
2
6 mono - Mono's ECMA-CLI native code generator (Just-in-Time and Ahead-
7 of-Time)
8
10 mono [options] file [arguments...]
11
13 mono is a runtime implementation of the ECMA Common Language Infra‐
14 structure. This can be used to run ECMA and .NET applications.
15 The runtime contains a native code generator that transforms the Common
17 Intermediate Language into native code.
18 The code generator can operate in two modes: just in time compilation
20 (JIT) or ahead of time compilation (AOT). Since code can be dynami‐
21 cally loaded, the runtime environment and the JIT are always present,
22 even if code is compiled ahead of time.
23 The runtime loads the specified file and optionally passes the argu‐
25 ments to it. The file is an ECMA assembly. They typically have a .exe
26 or .dll extension.
27 The runtime provides a number of configuration options for running
29 applications, for developing and debugging, and for testing and debug‐
30 ging the runtime itself.
31
33 On Unix-based systems, Mono provides a mechanism to emulate the Win‐
34 dows-style file access, this includes providing a case insensitive view
35 of the file system, directory separator mapping (from \ to /) and
36 stripping the drive letters.
37 This functionality is enabled by setting the MONO_IOMAP environment
39 variable to one of all, drive and case.
40 See the description for MONO_IOMAP in the environment variables section
42 for more details.
43
45 The following options are available:
46 --aot This option is used to precompile the CIL code in the specified
48 assembly to native code. The generated code is stored in a file
49 with the extension .so. This file will be automatically picked
50 up by the runtime when the assembly is executed.
51 Ahead-of-Time compilation is most useful if you use it in combi‐
53 nation with the -O=all,-shared flag which enables all of the
54 optimizations in the code generator to be performed. Some of
55 those optimizations are not practical for Just-in-Time compila‐
56 tion since they might be very time consuming.
57 Unlike the .NET Framework, Ahead-of-Time compilation will not
59 generate domain independent code: it generates the same code
60 that the Just-in-Time compiler would produce. Since most
61 applications use a single domain, this is fine. If you want to
62 optimize the generated code for use in multi-domain applica‐
63 tions, consider using the -O=shared flag.
64 This pre-compiles the methods, but the original assembly is
66 still required to execute as this one contains the metadata and
67 exception information which is not available on the generated
68 file. When precompiling code, you might want to compile with
69 all optimizations (-O=all). Pre-compiled code is position inde‐
70 pendent code.
71 Pre compilation is just a mechanism to reduce startup time,
73 increase code sharing across multiple mono processes and avoid
74 just-in-time compilation program startup costs. The original
75 assembly must still be present, as the metadata is contained
76 there.
77 For more information about AOT, see: http://www.mono-
79 project.com/AOT
80 --config filename
82 Load the specified configuration file instead of the default
83 one(s). The default files are /etc/mono/config and ~/.mono/con‐
84 fig or the file specified in the MONO_CONFIG environment vari‐
85 able, if set. See the mono-config(5) man page for details on
86 the format of this file.
87 --desktop
89 Configures the virtual machine to be better suited for desktop
90 applications. Currently this sets the GC system to avoid
91 expanding the heap as much as possible at the expense of slowing
92 down garbage collection a bit.
93 --help , -h
95 Displays usage instructions.
96 --optimize=MODE , -O=MODE
98 MODE is a comma separated list of optimizations. They also
99 allow optimizations to be turned off by prefixing the optimiza‐
100 tion name with a minus sign.
101 The following optimizations are implemented:
103 all Turn on all optimizations
104 peephole Peephole postpass
105 branch Branch optimizations
106 inline Inline method calls
107 cfold Constant folding
108 consprop Constant propagation
109 copyprop Copy propagation
110 deadce Dead code elimination
111 linears Linear scan global reg allocation
112 cmov Conditional moves
113 shared Emit per-domain code
114 sched Instruction scheduling
115 intrins Intrinsic method implementations
116 tailc Tail recursion and tail calls
117 loop Loop related optimizations
118 fcmov Fast x86 FP compares
119 leaf Leaf procedures optimizations
120 aot Usage of Ahead Of Time compiled code
121 precomp Precompile all methods before executing Main
122 abcrem Array bound checks removal
123 ssapre SSA based Partial Redundancy Elimination
124 For example, to enable all the optimization but dead code elimi‐
126 nation and inlining, you can use:
127 -O=all,-deadce,-inline
128 --runtime=VERSION
130 Mono supports different runtime versions. The version used
131 depends on the program that is being run or on its configuration
132 file (named program.exe.config). This option can be used to
133 override such autodetection, by forcing a different runtime ver‐
134 sion to be used. Note that this should only be used to select a
135 later compatible runtime version than the one the program was
136 compiled against. A typical usage is for running a 1.1 program
137 on a 2.0 version:
138 mono --runtime=v2.0.50727 program.exe
139 --security
141 Activate the security manager (experimental feature in 1.1).
142 This allows mono to support declarative security attributes
143 (e.g. execution of, CAS or non-CAS, security demands). The secu‐
144 rity manager is OFF by default (experimental).
145 --server
147 Configures the virtual machine to be better suited for server
148 operations.
149 -V , --version
151 Prints JIT version information.
152
156 The following options are used to help when developing a JITed applica‐
157 tion.
158 --debug
160 Turns on the debugging mode in the runtime. If an assembly was
161 compiled with debugging information, it will produce line number
162 information for stack traces.
163 --profile[=profiler[:profiler_args]]
165 Turns on profiling. For more information about profiling appli‐
166 cations and code coverage see the sections "PROFILING" and "CODE
167 COVERAGE" below.
168 --trace[=expression]
170 Shows method names as they are invoked. By default all methods
171 are traced.
172 The trace can be customized to include or exclude methods,
174 classes or assemblies. A trace expression is a comma separated
175 list of targets, each target can be prefixed with a minus sign
176 to turn off a particular target. The words `program', `all' and
177 `disabled' have special meaning. `program' refers to the main
178 program being executed, and `all' means all the method calls.
179 The `disabled' option is used to start up with tracing disabled.
181 It can be enabled at a later point in time in the program by
182 sending the SIGUSR2 signal to the runtime.
183 Assemblies are specified by their name, for example, to trace
185 all calls in the System assembly, use:
186 mono --trace=System app.exe
188 Classes are specified with the T: prefix. For example, to trace
190 all calls to the System.String class, use:
191 mono --trace=T:System.String app.exe
193 And individual methods are referenced with the M: prefix, and
195 the standard method notation:
196 mono --trace=M:System.Console:WriteLine app.exe
198 As previously noted, various rules can be specified at once:
200 mono --trace=T:System.String,T:System.Random app.exe
202 You can exclude pieces, the next example traces calls to Sys‐
204 tem.String except for the System.String:Concat method.
205 mono --trace=T:System.String,-M:System.String:Concat
207 Finally, namespaces can be specified using the N: prefix:
209 mono --trace=N:System.Xml
211
214 The maintainer options are only used by those developing the runtime
215 itself, and not typically of interest to runtime users or developers.
216 --break method
218 Inserts a breakpoint before the method whose name is `method'
219 (namespace.class:methodname). Use `Main' as method name to
220 insert a breakpoint on the application's main method.
221 --breakonex
223 Inserts a breakpoint on exceptions. This allows you to debug
224 your application with a native debugger when an exception is
225 thrown.
226 --compile name
228 This compiles a method (namespace.name:methodname), this is used
229 for testing the compiler performance or to examine the output of
230 the code generator.
231 --compileall
233 Compiles all the methods in an assembly. This is used to test
234 the compiler performance or to examine the output of the code
235 generator
236 --graph=TYPE METHOD
238 This generates a postscript file with a graph with the details
239 about the specified method (namespace.name:methodname). This
240 requires `dot' and ghostview to be installed (it expects Ghost‐
241 view to be called "gv").
242 The following graphs are available:
244 cfg Control Flow Graph (CFG)
245 dtree Dominator Tree
246 code CFG showing code
247 ssa CFG showing code after SSA translation
248 optcode CFG showing code after IR optimizations
249 Some graphs will only be available if certain optimizations are
251 turned on.
252 --ncompile
254 Instruct the runtime on the number of times that the method
255 specified by --compile (or all the methods if --compileall is
256 used) to be compiled. This is used for testing the code genera‐
257 tor performance.
258 --stats
260 Displays information about the work done by the runtime during
261 the execution of an application.
262 --wapi=hps|semdel
264 Perform maintenance of the process shared data.
265 semdel will delete the global semaphore.
267 hps will list the currently used handles.
269 -v , --verbose
271 Increases the verbosity level, each time it is listed, increases
272 the verbosity level to include more information (including, for
273 example, a disassembly of the native code produced, code selec‐
274 tor info etc.).
275
277 The mono runtime includes a profiler that can be used to explore vari‐
278 ous performance related problems in your application. The profiler is
279 activated by passing the --profile command line argument to the Mono
280 runtime, the format is:
281 --profile[=profiler[:profiler_args]]
283 Mono has a built-in profiler called 'default' (and is also the default
285 if no arguments are specified), but developers can write custom profil‐
286 ers, see the section "CUSTOM PROFILERS" for more details.
287 If a profiler is not specified, the default profiler is used.
289 The profiler_args is a profiler-specific string of options for the pro‐
291 filer itself.
292 The default profiler accepts the following options 'alloc' to profile
294 memory consumption by the application; 'time' to profile the time spent
295 on each routine; 'jit' to collect time spent JIT-compiling methods and
296 'stat' to perform sample statistical profiling. If no options are pro‐
297 vided the default is 'alloc,time,jit'.
298 By default the profile data is printed to stdout: to change this, use
300 the 'file=filename' option to output the data to filename.
301 For example:
303 mono --profile program.exe
305 That will run the program with the default profiler and will do time
308 and allocation profiling.
309 mono --profile=default:stat,alloc,file=prof.out program.exe
312 Will do sample statistical profiling and allocation profiling on pro‐
314 gram.exe. The profile data is put in prof.out.
315 Note that the statistical profiler has a very low overhead and should
317 be the preferred profiler to use (for better output use the full path
318 to the mono binary when running and make sure you have installed the
319 addr2line utility that comes from the binutils package).
320
322 There are a number of external profilers that have been developed for
323 Mono, we will update this section to contain the profilers.
324 The heap Shot profiler can track all live objects, and references to
326 these objects, and includes a GUI tool, this is our recommended pro‐
327 filer. To install you must download the profiler from Mono's SVN:
328 svn co svn://svn.myrealbox.com/source/trunk/heap-shot
329 cd heap-shot
330 ./autogen
331 make
332 make install
333 See the included documentation for details on using it.
335 The Live Type profiler shows at every GC iteration all of the live
337 objects of a given type. To install you must download the profiler
338 from Mono's SVN:
339 svn co svn://svn.myrealbox.com/source/trunk/heap-prof
340 cd heap-prof
341 ./autogen
342 make
343 make install
344 To use the profiler, execute:
346 mono --profile=desc-heap program.exe
347 The output of this profiler looks like this:
349 Checkpoint at 102 for heap-resize
350 System.MonoType : 708
351 System.Threading.Thread : 352
352 System.String : 3230
353 System.String[] : 104
354 Gnome.ModuleInfo : 112
355 System.Object[] : 160
356 System.Collections.Hashtable : 96
357 System.Int32[] : 212
358 System.Collections.Hashtable+Slot[] : 296
359 System.Globalization.CultureInfo : 108
360 System.Globalization.NumberFormatInfo : 144
361 The first line describes the iteration number for the GC, in this case
363 checkpoint 102.
364 Then on each line the type is displayed as well as the number of bytes
366 that are being consumed by live instances of this object.
367 The AOT profiler is used to feed back information to the AOT compiler
369 about how to order code based on the access patterns for pages. To use
370 it, use:
371 mono --profile=aot program.exe
372 The output of this profile can be fed back into Mono's AOT compiler to
373 order the functions on the disk to produce precompiled images that have
374 methods in sequential pages.
375
377 Mono provides a mechanism for loading other profiling modules which in
378 the form of shared libraries. These profiling modules can hook up to
379 various parts of the Mono runtime to gather information about the code
380 being executed.
381 To use a third party profiler you must pass the name of the profiler to
383 Mono, like this:
384 mono --profile=custom program.exe
386 In the above sample Mono will load the user defined profiler from the
389 shared library `mono-profiler-custom.so'. This profiler module must be
390 on your dynamic linker library path.
391 A list of other third party profilers is available from Mono's web site
393 (www.mono-project.com/Performance_Tips)
394 Custom profiles are written as shared libraries. The shared library
396 must be called `mono-profiler-NAME.so' where `NAME' is the name of your
397 profiler.
398 For a sample of how to write your own custom profiler look in the Mono
400 source tree for in the samples/profiler.c.
401
403 Mono ships with a code coverage module. This module is activated by
404 using the Mono --profile=cov option. The format is: --pro‐
405 file=cov[:assembly-name[/namespace]] test-suite.exe
406 By default code coverage will default to all the assemblies loaded, you
408 can limit this by specifying the assembly name, for example to perform
409 code coverage in the routines of your program use, for example the fol‐
410 lowing command line limits the code coverage to routines in the "demo"
411 assembly:
412 mono --profile=cov:demo demo.exe
414 Notice that the assembly-name does not include the extension.
417 You can further restrict the code coverage output by specifying a
419 namespace:
420 mono --profile=cov:demo/My.Utilities demo.exe
422 Which will only perform code coverage in the given assembly and names‐
425 pace.
426 Typical output looks like this:
428 Not covered: Class:.ctor ()
430 Not covered: Class:A ()
431 Not covered: Driver:.ctor ()
432 Not covered: Driver:method ()
433 Partial coverage: Driver:Main ()
434 offset 0x000a
435 The offsets displayed are IL offsets.
438 A more powerful coverage tool is available in the module `monocov'.
440 See the monocov(1) man page for details.
441
443 It is possible to obtain a stack trace of all the active threads in
444 Mono by sending the QUIT signal to Mono, you can do this from the com‐
445 mand line, like this:
446 kill -QUIT pid
448 Where pid is the Process ID of the Mono process you want to examine.
450 The process will continue running afterwards, but its state is not
451 guaranteed.
452 Important: this is a last-resort mechanism for debugging applications
454 and should not be used to monitor or probe a production application.
455 The integrity of the runtime after sending this signal is not guaran‐
456 teed and the application might crash or terminate at any given point
457 afterwards.
458 You can use the MONO_LOG_LEVEL and MONO_LOG_MASK environment variables
460 to get verbose debugging output about the execution of your application
461 within Mono.
462 The MONO_LOG_LEVEL environment variable if set, the logging level is
464 changed to the set value. Possible values are "error", "critical",
465 "warning", "message", "info", "debug". The default value is "error".
466 Messages with a logging level greater then or equal to the log level
467 will be printed to stdout/stderr.
468 Use "info" to track the dynamic loading of assemblies.
470 Use the MONO_LOG_MASK environment variable to limit the extent of the
472 messages you get: If set, the log mask is changed to the set value.
473 Possible values are "asm" (assembly loader), "type", "dll" (native
474 library loader), "gc" (garbage collector), "cfg" (config file loader),
475 "aot" (precompiler) and "all". The default value is "all". Changing
476 the mask value allows you to display only messages for a certain compo‐
477 nent. You can use multiple masks by comma separating them. For example
478 to see config file messages and assembly loader messages set you mask
479 to "asm,cfg".
480 The following is a common use to track down problems with P/Invoke:
482 $ MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" mono glue.exe
484
487 Mono's XML serialization engine by default will use a reflection-based
488 approach to serialize which might be slow for continuous processing
489 (web service applications). The serialization engine will determine
490 when a class must use a hand-tuned serializer based on a few parameters
491 and if needed it will produce a customized C# serializer for your types
492 at runtime. This customized serializer then gets dynamically loaded
493 into your application.
494 You can control this with the MONO_XMLSERIALIZER_THS environment vari‐
496 able.
497 The possible values are `no' to disable the use of a C# customized
499 serializer, or an integer that is the minimum number of uses before the
500 runtime will produce a custom serializer (0 will produce a custom seri‐
501 alizer on the first access, 50 will produce a serializer on the 50th
502 use). Mono will fallback to an interpreted serializer if the serializer
503 generation somehow fails. This behavior can be disabled by setting the
504 option `nofallback' (for example: MONO_XMLSERIALIZER_THS=0,nofallback).
505
507 GC_DONT_GC
508 Turns off the garbage collection in Mono. This should be only
509 used for debugging purposes
510 MONO_AOT_CACHE
512 If set, this variable will instruct Mono to ahead-of-time com‐
513 pile new assemblies on demand and store the result into a cache
514 in ~/.mono/aot-cache.
515 MONO_CFG_DIR
517 If set, this variable overrides the default system configuration
518 directory ($PREFIX/etc). It's used to locate machine.config
519 file.
520 MONO_CONFIG
522 If set, this variable overrides the default runtime configura‐
523 tion file ($PREFIX/etc/mono/config). The --config command line
524 options overrides the environment variable.
525 MONO_DEBUG
527 If set, enables some features of the runtime useful for debug‐
528 ging. This variable should contain a comma separated list of
529 debugging options. Currently, the following options are sup‐
530 ported:
531 collect-pagefault-stats
533 Collects information about pagefaults. This is used
534 internally to track the number of page faults produced to
535 load metadata. To display this information you must use
536 this option with "--stats" command line option.
537 handle-sigint
539 Captures the interrupt signal (Control-C) and displays a
540 stack trace when pressed. Useful to find out where the
541 program is executing at a given point. This only dis‐
542 plays the stack trace of a single thread.
543 keep-delegates
545 This option will leak delegate trampolines that are no
546 longer referenced as to present the user with more infor‐
547 mation about a delegate misuse. Basically a delegate
548 instance might be created, passed to unmanaged code, and
549 no references kept in managed code, which will garbage
550 collect the code. With this option it is possible to
551 track down the source of the problems.
552 break-on-unverified
554 If this variable is set, when the Mono VM runs into a
555 verification problem, instead of throwing an exception it
556 will break into the debugger. This is useful when debug‐
557 ging verifier problems
558 MONO_DISABLE_AIO
560 If set, tells mono NOT to attempt using native asynchronous I/O
561 services. In that case, a default select/poll implementation is
562 used. Currently only epoll() is supported.
563 MONO_DISABLE_MANAGED_COLLATION
565 If this environment variable is `yes', the runtime uses unman‐
566 aged collation (which actually means no culture-sensitive colla‐
567 tion). It internally disables managed collation functionality
568 invoked via the members of System.Globalization.CompareInfo
569 class. Collation is enabled by default.
570 MONO_EGD_SOCKET
572 For platforms that do not otherwise have a way of obtaining ran‐
573 dom bytes this can be set to the name of a file system socket on
574 which an egd or prngd daemon is listening.
575 MONO_EVENTLOG_TYPE
577 Sets the type of event log provider to use (for System.Diagnos‐
578 tics.EventLog).
579 Possible values are:
581 local[:path]
583 Persists event logs and entries to the local file system.
585 The directory in which to persist the event logs, event
587 sources and entries can be specified as part of the
588 value.
589 If the path is not explicitly set, it defaults to
591 "/var/lib/mono/eventlog" on unix and "%APPDATA%no\vent‐
592 log" on Windows.
593 win32
595 Uses the native win32 API to write events and registers
597 event logs and event sources in the registry. This is
598 only available on Windows.
599 On Unix, the directory permission for individual event
601 log and event source directories is set to 777 (with +t
602 bit) allowing everyone to read and write event log
603 entries while only allowing entries to be deleted by the
604 user(s) that created them.
605 null
607 Silently discards any events.
609 The default is "null" on Unix (and versions of Windows before
611 NT), and "win32" on Windows NT (and higher).
612 MONO_EXTERNAL_ENCODINGS
614 If set, contains a colon-separated list of text encodings to try
615 when turning externally-generated text (e.g. command-line argu‐
616 ments or filenames) into Unicode. The encoding names come from
617 the list provided by iconv, and the special case
618 "default_locale" which refers to the current locale's default
619 encoding.
620 When reading externally-generated text strings UTF-8 is tried
622 first, and then this list is tried in order with the first suc‐
623 cessful conversion ending the search. When writing external
624 text (e.g. new filenames or arguments to new processes) the
625 first item in this list is used, or UTF-8 if the environment
626 variable is not set.
627 The problem with using MONO_EXTERNAL_ENCODINGS to process your
629 files is that it results in a problem: although its possible to
630 get the right file name it is not necessarily possible to open
631 the file. In general if you have problems with encodings in
632 your filenames you should use the "convmv" program.
633 MONO_GAC_PREFIX
635 Provides a prefix the runtime uses to look for Global Assembly
636 Caches. Directories are separated by the platform path separa‐
637 tor (colons on unix). MONO_GAC_PREFIX should point to the top
638 directory of a prefixed install. Or to the directory provided in
639 the gacutil /gacdir command. Example: /home/user‐
640 name/.mono:/usr/local/mono/
641 MONO_IOMAP
643 Enables some filename rewriting support to assist badly-written
644 applications that hard-code Windows paths. Set to a colon-sepa‐
645 rated list of "drive" to strip drive letters, or "case" to do
646 case-insensitive file matching in every directory in a path.
647 "all" enables all rewriting methods. (Backslashes are always
648 mapped to slashes if this variable is set to a valid option.)
649 For example, this would work from the shell:
651 MONO_IOMAP=drive:case
653 export MONO_IOMAP
654 If you are using mod_mono to host your web applications, you can
656 use the MonoSetEnv directive, like this:
657 MonoSetEnv MONO_IOMAP=all
659 MONO_MANAGED_WATCHER
662 If set to any value, System.IO.FileSystemWatcher will use the
663 default managed implementation (slow). If unset, mono will try
664 to use FAM under Unix systems and native API calls on Windows,
665 falling back to the managed implementation on error.
666 MONO_PATH
668 Provides a search path to the runtime where to look for library
669 files. This is a tool convenient for debugging applications,
670 but should not be used by deployed applications as it breaks the
671 assembly loader in subtle ways.
672 Directories are separated by the platform path separator (colons
674 on unix). Example: /home/username/lib:/usr/local/mono/lib
675 Alternative solutions to MONO_PATH include: installing libraries
677 into the Global Assembly Cache (see gacutil(1)) or having the
678 dependent libraries side-by-side with the main executable.
679 For a complete description of recommended practices for applica‐
681 tion deployment, see the http://www.mono-project.com/Guide‐
682 lines:Application_Deployment page.
683 MONO_RTC
685 Experimental RTC support in the statistical profiler: if the
686 user has the permission, more accurate statistics are gathered.
687 The MONO_RTC value must be restricted to what the Linux rtc
688 allows: power of two from 64 to 8192 Hz. To enable higher fre‐
689 quencies like 4096 Hz, run as root:
690 echo 4096 > /proc/sys/dev/rtc/max-user-freq
692 For example:
695 MONO_RTC=4096 mono --profiler=default:stat program.exe
697 MONO_NO_TLS
700 Disable inlining of thread local accesses. Try setting this if
701 you get a segfault early on in the execution of mono.
702 MONO_SHARED_DIR
704 If set its the directory where the ".wapi" handle state is
705 stored. This is the directory where the Windows I/O Emulation
706 layer stores its shared state data (files, events, mutexes,
707 pipes). By default Mono will store the ".wapi" directory in the
708 users's home directory.
709 MONO_SHARED_HOSTNAME
711 Uses the string value of this variable as a replacement for the
712 host name when creating file names in the ".wapi" directory.
713 This helps if the host name of your machine is likely to be
714 changed when a mono application is running or if you have a
715 .wapi directory shared among several different computers.
716 Mono typically uses the hostname to create the files that are
718 used to share state across multiple Mono processes. This is
719 done to support home directories that might be shared over the
720 network.
721 MONO_STRICT_IO_EMULATION
723 If set, extra checks are made during IO operations. Currently,
724 this includes only advisory locks around file writes.
725 MONO_THEME
727 The name of the theme to be used by Windows.Forms. Available
728 themes today include "clearlooks", "nice" and "win32".
729 The default is "win32".
731 MONO_TLS_SESSION_CACHE_TIMEOUT
733 The time, in seconds, that the SSL/TLS session cache will keep
734 it's entry to avoid a new negotiation between the client and a
735 server. Negotiation are very CPU intensive so an application-
736 specific custom value may prove useful for small embedded sys‐
737 tems.
738 The default is 180 seconds.
740 MONO_THREADS_PER_CPU
742 The maximum number of threads in the general threadpool will be
743 20 + (MONO_THREADS_PER_CPU * number of CPUs). The default value
744 for this variable is 5.
745 MONO_XMLSERIALIZER_THS
747 Controls the threshold for the XmlSerializer to produce a custom
748 serializer for a given class instead of using the Reflection-
749 based interpreter. The possible values are `no' to disable the
750 use of a custom serializer or a number to indicate when the
751 XmlSerializer should start serializing. The default value is
752 50, which means that the a custom serializer will be produced on
753 the 50th use.
754 MONO_XMLSERIALIZER_DEBUG
756 Set this value to 1 to prevent the serializer from removing the
757 temporary files that are created for fast serialization; This
758 might be useful when debugging.
759
761 MONO_ASPNET_NODELETE
762 If set to any value, temporary source files generated by ASP.NET
763 support classes will not be removed. They will be kept in the
764 user's temporary directory.
765 MONO_LOG_LEVEL
767 The logging level, possible values are `error', `critical',
768 `warning', `message', `info' and `debug'. See the DEBUGGING
769 section for more details.
770 MONO_LOG_MASK
772 Controls the domain of the Mono runtime that logging will apply
773 to. If set, the log mask is changed to the set value. Possible
774 values are "asm" (assembly loader), "type", "dll" (native
775 library loader), "gc" (garbage collector), "cfg" (config file
776 loader), "aot" (precompiler) and "all". The default value is
777 "all". Changing the mask value allows you to display only mes‐
778 sages for a certain component. You can use multiple masks by
779 comma separating them. For example to see config file messages
780 and assembly loader messages set you mask to "asm,cfg".
781 MONO_TRACE
783 Used for runtime tracing of method calls. The format of the
784 comma separated trace options is:
785 [-]M:method name
787 [-]N:namespace
788 [-]T:class name
789 [-]all
790 [-]program
791 disabled Trace output off upon start.
792 You can toggle trace output on/off sending a SIGUSR2 signal to
794 the program.
795 MONO_TRACE_LISTENER
797 If set, enables the System.Diagnostics.DefaultTraceListener,
798 which will print the output of the System.Diagnostics Trace and
799 Debug classes. It can be set to a filename, and to Console.Out
800 or Console.Error to display output to standard output or stan‐
801 dard error, respectively. If it's set to Console.Out or Con‐
802 sole.Error you can append an optional prefix that will be used
803 when writing messages like this: Console.Error:MyProgramName.
804 See the System.Diagnostics.DefaultTraceListener documentation
805 for more information.
806 MONO_XEXCEPTIONS
808 This throws an exception when a X11 error is encountered; by
809 default a message is displayed but execution continues
810 MONO_XSYNC
812 This is used in the System.Windows.Forms implementation when
813 running with the X11 backend. This is used to debug problems in
814 Windows.Forms as it forces all of the commands send to X11
815 server to be done synchronously. The default mode of operation
816 is asynchronous which makes it hard to isolate the root of cer‐
817 tain problems.
818
820 If you want to use Valgrind, you will find the file `mono.supp' useful,
821 it contains the suppressions for the GC which trigger incorrect warn‐
822 ings. Use it like this:
823 valgrind --suppressions=mono.supp mono ...
824
826 On Unix assemblies are loaded from the installation lib directory. If
827 you set `prefix' to /usr, the assemblies will be located in /usr/lib.
828 On Windows, the assemblies are loaded from the directory where mono and
829 mint live.
830 ~/.mono/aot-cache
832 The directory for the ahead-of-time compiler demand creation
834 assemblies are located.
835 /etc/mono/config, ~/.mono/config
837 Mono runtime configuration file. See the mono-config(5) manual
839 page for more information.
840 ~/.config/.mono/certs, /usr/share/.mono/certs
842 Contains Mono certificate stores for users / machine. See the
844 certmgr(1) manual page for more information on managing certifi‐
845 cate stores and the mozroots(1) page for information on how to
846 import the Mozilla root certificates into the Mono certificate
847 store.
848 ~/.mono/assemblies/ASSEMBLY/ASSEMBLY.config
850 Files in this directory allow a user to customize the configura‐
852 tion for a given system assembly, the format is the one
853 described in the mono-config(5) page.
854 ~/.config/.mono/keypairs, /usr/share/.mono/keypairs
856 Contains Mono cryptographic keypairs for users / machine. They
858 can be accessed by using a CspParameters object with DSACryp‐
859 toServiceProvider and RSACryptoServiceProvider classes.
860 ~/.config/.isolatedstorage, ~/.local/share/.isolatedstorage,
862 /usr/share/.isolatedstorage
863 Contains Mono isolated storage for non-roaming users, roaming
865 users and local machine. Isolated storage can be accessed using
866 the classes from the System.IO.IsolatedStorage namespace.
867 <assembly>.config
869 Configuration information for individual assemblies is loaded by
871 the runtime from side-by-side files with the .config files, see
872 the http://www.mono-project.com/Config for more information.
873 Web.config, web.config
875 ASP.NET applications are configured through these files, the
877 configuration is done on a per-directory basis. For more infor‐
878 mation on this subject see the http://www.mono-project.com/Con‐
879 fig_system.web page.
880
882 Mailing lists are listed at the http://www.mono-project.com/Mail‐
883 ing_Lists
884
886 http://www.mono-project.com
887
889 certmgr(1), mcs(1), monocov(1), monodis(1), mono-config(5), moz‐
890 roots(1), xsp(1).
891 For more information on AOT: http://www.mono-project.com/AOT
893 For ASP.NET-related documentation, see the xsp(1) manual page
895 Mono(Mono 1.0)