Mono(mono) Mono(mono)

mono - تولیدکننده کد بومی ECMA-CLI در مونو (Just-in-Time و Ahead-of-Time)

mono [options] file [arguments...]

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

mono یک پیاده‌سازی زمان اجرا از زیرساخت زبان مشترک ECMA (موسوم به Common Language Infrastructure) است. از این ابزار می‌توان برای اجرای برنامه‌های ECMA و .NET استفاده کرد.

محیط زمان اجرا، file مشخص‌شده را بارگذاری کرده و در صورت تمایل، arguments را به آن ارسال می‌کند. file یک اسمبلی ECMA است؛ این فایل‌ها معمولاً دارای پسوند .exe یا .dll هستند.

این فایل‌های اجرایی می‌توانند در قالب ارجاعات اسمبلی (assembly references) به قابلیت‌های دیگری ارجاع دهند. به‌طور پیش‌فرض، این ارجاعات اسمبلی بدین صورت حل‌وفصل می‌شوند: mscorlib.dll بر اساس نمایهٔ سیستمی پیکربندی‌شده توسط Mono تعیین می‌شود و سایر اسمبلی‌ها از حافظهٔ سراسری اسمبلی (Global Assembly Cache یا GAC) بارگذاری می‌گردند.

محیط زمان اجرا شامل یک تولیدکننده کد بومی است که Common Intermediate Language را به کد بومی (native code) تبدیل می‌کند.

تولیدکننده کد می‌تواند در دو حالت عمل کند: کامپایل درجا (Just-in-time compilation یا JIT) یا کامپایل پیش‌هنگام (Ahead-of-time compilation یا AOT). از آنجا که کدها می‌توانند به‌طور پویا بارگذاری شوند، محیط زمان اجرا و کامپایلر JIT همواره حاضر هستند، حتی اگر کد از قبل به‌صورت پیش‌هنگام کامپایل شده باشد.

محیط زمان اجرا گزینه‌های پیکربندی متعددی را برای اجرای برنامه‌ها، توسعه و اشکال‌زدایی، و نیز آزمایش و اشکال‌زداییِ خودِ محیط زمان اجرا فراهم می‌کند.

دستور mono از زباله‌روبِ جابجاشونده و نسلیِ SGen استفاده می‌کند، در حالی که دستور mono-boehm از زباله‌روب محافظه‌کار Boehm بهره می‌برد.

در سیستم‌های مبتنی بر Unix، مونو مکانیزمی را برای شبیه‌سازی دسترسی به فایل‌ها به سبک Windows فراهم می‌کند؛ این سازوکار شامل ارائهٔ یک نمای غیرحساس به بزرگی و کوچکی حروف از سیستم‌فایل، نگاشت جداکننده دایرکتوری‌ها (از \ به /) و حذف حروف مربوط به درایو است.

این قابلیت با مقداردهی متغیر محیطی MONO_IOMAP به یکی از مقادیر all ، drive و case فعال می‌شود.

برای جزئیات بیشتر، توضیحات مربوط به MONO_IOMAP را در بخش متغیرهای محیطی ببینید.

تعدادی از گزینه‌های خط فرمان برای عیب‌یابی، توصیف یک متد را به عنوان آرگومان دریافت می‌کنند. توصیف متد، یک نمایش متنی است که می‌توان از آن برای شناسایی یکتای یک متد استفاده کرد. ساختار نگارش آن به صورت زیر است:

[namespace]classname:methodname[(arguments)]

مقادیر داخل براکت اختیاری هستند، مانند فضای نام (namespace) و آرگومان‌ها. خود آرگومان‌ها نیز یا خالی هستند، یا فهرستی از آرگومان‌ها که با کاما از هم جدا شده‌اند. هر دو مورد classname و methodname می‌توانند با مقدار ویژهٔ '*' مقداردهی شوند تا با هر مقداری تطابق یابند (کاربران شل Unix باید این آرگومان را escape کنند تا شل آن را تفسیر نکند).

آرگومان‌ها در صورت وجود، باید فهرستی از انواع داده باشند که با کاما جدا شده‌اند؛ چه نام کامل یک نوع (typename) و چه برای انواع توکار (built-in)، باید از نام‌های سطح‌پایین نوع در ILAsm استفاده شود، مانند 'void'،‏ 'char'،‏ 'bool'،‏ 'byte'،‏ 'sbyte'،‏ 'uint16'،‏ 'int16'،‏ 'uint'، 'int'،‏ 'ulong'،‏ 'long'،‏ 'uintptr'،‏ 'intptr'،‏ 'single'،‏ 'double'،‏ 'string'،‏ 'object'.

انواع اشاره‌گر باید شامل نام نوع و به‌دنبال آن یک '*' باشند؛ آرایه‌ها باید نام نوع و به‌دنبال آن '['، یک یا چند کاما (برای مشخص کردن بُعد یا رتبهٔ آرایه) و ']' باشند.

مقادیر جنریک (Generic) باید با استفاده از '<'، یک یا چند نام نوع که با کاما و فاصله از هم جدا شده‌اند، و سپس '>' مشخص شوند.

آرگومان‌های ارجاعی (By-reference) باید شامل یک "&" پس از نام نوع باشند.

مثال‌ها:

*:ctor(int)		// تمامی سازنده‌هایی که یک int به عنوان آرگومان دریافت می‌کنند
*:Main			// متدهای با نام Main در هر کلاس
*:Main(string[])	// متدهای با نام Main در هر کلاس که یک آرایه string دریافت می‌کنند
گزینه‌های زیر در دسترس هستند:
این گزینه برای پیش‌کامپایل کردن کد CIL در اسمبلی (assembly) مشخص‌شده به کد محلی (native code) به کار می‌رود. کد تولیدشده در فایلی با پسوند .so ذخیره می‌شود. این فایل هنگام اجرای اسمبلی، به‌طور خودکار توسط محیط زمان اجرا (runtime) شناسایی و بارگذاری خواهد شد.
کامپایل پیش‌هنگام (Ahead-of-Time یا AOT) بیشترین کارایی را زمانی دارد که در ترکیب با پرچم ‎-O=all,-shared استفاده شود؛ پرچمی که اعمال همه بهینه‌سازی‌ها را در تولیدکننده کد فعال می‌سازد. برخی از این بهینه‌سازی‌ها برای کامپایل درجا (Just-in-Time یا JIT) عملی نیستند زیرا ممکن است بسیار زمان‌بر باشند.
برخلاف ‎.NET Framework، کامپایل پیش‌هنگام کد مستقل از دامنه تولید نمی‌کند: این سازوکار همان کدی را تولید می‌کند که کامپایلر درجا (JIT) تولید می‌کرد. از آنجا که بیشتر برنامه‌ها از یک دامنه واحد استفاده می‌کنند، این مسئله مشکلی به وجود نمی‌آورد. اگر می‌خواهید کد تولیدشده را برای استفاده در برنامه‌های چنددامنه‌ای بهینه‌سازی کنید، استفاده از پرچم ‎-O=shared را مد نظر قرار دهید.
این قابلیت متدها را پیش‌کامپایل می‌کند، اما اسمبلی اصلی همچنان برای اجرا مورد نیاز است زیرا حاوی متادیتا و اطلاعات استثناهاست که در فایل تولیدشده موجود نیستند. هنگام پیش‌کامپایل کد، ممکن است مایل باشید آن را با تمام بهینه‌سازی‌ها (‎-O=all) کامپایل کنید. کد پیش‌کامپایل‌شده یک کد مستقل از موقعیت (position independent code) است.
پیش‌کامپایل صرفاً سازوکاری برای کاهش زمان راه‌اندازی، افزایش اشتراک‌گذاری کد میان چندین فرایند mono و اجتناب از هزینه‌های راه‌اندازی ناشی از کامپایل درجا است. اسمبلی اصلی همچنان باید موجود باشد، زیرا متادیتا در آن قرار دارد.
کد AOT معمولاً نمی‌تواند از رایانه‌ای به رایانه دیگر منتقل شود (به دلیل بهینه‌سازی‌های مختص پردازنده که در زمان اجرا شناسایی می‌شوند)؛ بنابراین نباید تلاش کنید اسمبلی‌های از پیش تولیدشده را جابه‌جا کنید یا آن‌ها را برای استقرار (deployment) بسته‌بندی نمایید.
چند گزینه به عنوان پارامتر برای گزینه خط فرمان
--aot
در دسترس هستند. این گزینه‌ها با کاما از یکدیگر جدا می‌شوند و امکان مشخص کردن بیش از یک گزینه وجود دارد:
به کامپایلر AOT دستور می‌دهد تا به جای یک فایل شیء (object file)، کد اسمبلی خروجی دهد.
در صورت تعیین، فایل‌های AOT تولیدشده را وادار می‌کند تا به نسخه زمان اجرای Mono کامپایل‌کننده مقید شوند. این کار از استفاده فایل‌های AOT توسط یک زمان اجرای Mono دیگر جلوگیری می‌کند.
به تولیدکننده کد AOT دستور می‌دهد تا برخی ساختارهای داده‌ای را در یک فایل جداگانه ذخیره کند. این کار می‌تواند اندازه ایمیج‌های اجرایی را بین پنج تا بیست درصد کاهش دهد. سپس توسعه‌دهندگان باید aotdata حاصل را به عنوان یک منبع (resource) ارائه داده و با استفاده از متد
mono_install_load_aot_data_hook
هوک مربوطه را برای بارگذاری در صورت نیازِ (on-demand) داده‌ها ثبت نمایند.
هنگامی که این گزینه مشخص شود، فراخوانی‌های icall (فراخوانی‌های داخلی صورت‌گرفته از کتابخانه استاندارد به کد زمان اجرای mono) به جای گذر از عملیات جستجوی نماد سیستم‌عامل، مستقیماً فراخوانی می‌شوند. این امر مستلزم استفاده از گزینه
static
است.
هنگامی که این گزینه مشخص شود، متدهای P/Invoke به جای گذر از عملیات جستجوی نماد سیستم‌عامل، مستقیماً فراخوانی می‌شوند. این امر مستلزم استفاده از گزینه
static
است.
به کامپایلر AOT دستور می‌دهد تا اطلاعات اشکال‌زدایی DWARF را تولید کند. هنگام استفاده همزمان با گزینه nodebug، تنها اطلاعات اشکال‌زدایی DWARF تولید می‌شود، نه اطلاعاتی که بتوان در زمان اجرا از آن‌ها استفاده کرد.
باینری‌هایی تولید می‌کند که می‌توانند با گزینه ‎--full-aot استفاده شوند.
باینری‌هایی تولید می‌کند که می‌توانند با گزینه ‎--hybrid-aot استفاده شوند.
در صورت امکان، کامپایل AOT با بک‌اند LLVM به جای بک‌اند Mono انجام خواهد شد. این کار سرعت کامپایل را کاهش می‌دهد اما به احتمال زیاد منجر به بهبود عملکرد خواهد شد.
کامپایل AOT منحصراً با بک‌اند LLVM انجام شده و از بک‌اند Mono استفاده نخواهد شد. تنها خروجی در این حالت، فایل bitcode خواهد بود که معمولاً با گزینه
llvm-outfile
مشخص می‌شود. استفاده از
llvmonly
به‌طور خودکار گزینه‌های
full
و
llvm
را فعال می‌کند. این قابلیت آزمایشی است.
از این گزینه برای افزودن پرچم‌های بیشتر به مجموعه پرچم‌های داخلی ارسال‌شده به بهینه‌ساز LLVM استفاده کنید. هنگامی که دستور
mono
را با
--aot=llvm
فراخوانی می‌کنید، فهرست پرچم‌های فعلی که به دستور
opt
ارسال می‌شوند نمایش داده می‌شود.
فهرست پرچم‌های ممکن برای ارسال را می‌توان با فراخوانی برنامه
opt
همراه Mono به شکل زیر به دست آورد:
	opt --help
از این گزینه برای افزودن پرچم‌های بیشتر به مجموعه پرچم‌های توکار ارسال‌شده به کامپایلر ایستای LLVM (llc) استفاده کنید. فهرست پرچم‌های ممکن برای ارسال را می‌توان با فراخوانی برنامه llc همراه Mono به شکل زیر به دست آورد: 
llc --help
مقدار cpu=native به حالت AOT اجازه می‌دهد از تمام دستورالعمل‌هایی که پردازنده فعلی پشتیبانی می‌کند، مانند AVX2 ،SSE42 و غیره استفاده کند. مقدار پیش‌فرض 'generic' است. mattr=[cpu feature] به تولیدکننده کد AOT اجازه می‌دهد در صورت امکان از ویژگی‌های مشخص‌شده پردازنده از جمله `System.Runtime.Intrinsics.*` استفاده کند. برای مثال `mattr=+avx2,mattr=-lzcnt` قابلیت‌های sse1-4.2 و avx1-2 را فعال کرده و lzcnt را غیرفعال می‌کند. این ویژگی برای کامپایل متقاطع (cross-compilation) یا هنگامی که استفاده از `-mcpu=native` (که تمام قابلیت‌های پردازنده فعلی را فعال می‌کند) امکان‌پذیر نیست، مفید است. llvm-outfile=[filename] مسیر فایل موقت LLVM bitcode تولیدشده در حین AOT را تعیین می‌کند. dedup هر ماژول AOT معمولاً شامل کد متدهای بازشده (inflated methods) و لفاف‌هایی (wrappers) است که توسط کد درون آن ماژول فراخوانی می‌شوند. در حالت dedup، تمام آن متدها شناسایی شده و از کامپایل آن‌ها صرف‌نظر می‌شود. هنگام استفاده از این حالت با fullaot، مشخص کردن dedup-include الزامی است؛ در غیر این صورت این متدها مفقود باقی خواهند ماند.
در حالت dedup-include، در مرحله‌ای از کامپایل قرار داریم که در آن متدهایی که قبلاً نادیده گرفته شده بودند، کامپایل می‌شوند. همه آن‌ها در اسمبلی مشخص‌شده برای این گزینه قرار می‌گیرند. ما نسخه‌های تکراریِ نادیده‌گرفته‌شده از یک متد یکسان را در یک نسخه ادغام می‌کنیم.
معماری هدفی که AOT در این نسخه از Mono برای آن در نظر گرفته شده را چاپ کرده و خارج می‌شود.
تمام لفاف‌های لازم را تولید می‌کند تا اجرای ‎--interpreter بدون نیاز به تولید کد در زمان اجرا امکان‌پذیر باشد. این گزینه فقط با mscorlib.dll معنی دارد. برنامه‌های تعبیه‌کننده (Embedders) می‌توانند این مقدار را تنظیم کنند:
یک فایل وابستگی با ساختار gcc -M خروجی می‌دهد. 
mono_jit_set_aot_mode (MONO_AOT_MODE_INTERP);
پرچم‌های اضافی برای ارسال به پیونددهنده C (اگر حالت فعلی AOT نیازمند فراخوانی آن باشد)..TP llvm-path=<PREFIX> مشابهاً برای ابزارهای llvm با نام‌های 'opt' و 'llc'.
به کامپایلر AOT دستور می‌دهد تا فایل‌های sequence points برون‌خط با پسوند .msym را تولید کند. فایل‌های .msym تولید شده در زیرپوشه‌ای از <PATH> که به نام AOTID کامپایل نام‌گذاری شده ذخیره خواهند شد.
استفاده از سه‌گانه مقصد با سبک گنو <TRIPLE> برای تعیین برخی گزینه‌های تولید کد؛ مثلاً --mtriple=armv7-linux-gnueabi کدی تولید می‌کند که ARMv7 را هدف قرار می‌دهد. این قابلیت در حال حاضر تنها توسط بک‌اند ARM پشتیبانی می‌شود. در حالت LLVM، این سه‌گانه به کامپایلر llc در LLVM پاس داده می‌شود.
هنگام کامپایل در حالت full aot، ترامپولین‌های IMT باید از پیش در تصویر AOT ساخته شوند. با این آرگومان می‌توانید ترامپولین‌های متد بیشتری اضافه کنید. پیش‌فرض 512 است.
هنگام کامپایل در حالت full aot، ترامپولین‌های اشتراک‌گذاری جنریک از نوع مقدار (value type) باید از پیش در تصویر AOT ساخته شوند. با این آرگومان می‌توانید ترامپولین‌های متد بیشتری اضافه کنید. پیش‌فرض 512 است.
به کامپایلر AOT دستور می‌دهد هیچ‌گونه اطلاعات اشکال‌زدایی خروجی ندهد.
از تولید فراخوانی‌های مستقیم به یک متد توسط کامپایلر AOT جلوگیری می‌کند. کامپایلر AOT معمولاً فراخوانی‌های مستقیم را برای متدهای خاصی تولید می‌کند که نیازی به عبور از PLT ندارند (برای مثال، متدهایی که مشخص است نیازی به قلاب ندارند مانند سازنده ایستا) یا فراخوانی‌های داخلی ساده را انجام می‌دهند.
هنگام کامپایل در حالت full aot، ترامپولین‌های اشتراک‌گذاری جنریک باید از پیش در تصویر AOT ساخته شوند. با این آرگومان می‌توانید ترامپولین‌های متد بیشتری اضافه کنید. پیش‌فرض 4096 است.
هنگام کامپایل در حالت full aot، ترامپولین‌های واکشی اشتراک‌گذاری جنریک باید از پیش در تصویر AOT ساخته شوند. با این آرگومان می‌توانید ترامپولین‌های متد بیشتری اضافه کنید. پیش‌فرض 128 است.
هنگام کامپایل در حالت full aot، ترامپولین‌های متد باید از پیش در تصویر AOT ساخته شوند. با این آرگومان می‌توانید ترامپولین‌های متد بیشتری اضافه کنید. پیش‌فرض 4096 است.
به کامپایلر AOT دستور می‌دهد تا خروجی را در فایل مشخص‌شده ذخیره کند.
اگر کامپایلر AOT به هر دلیلی نتواند متدی را کامپایل کند، فعال‌سازی این پرچم متدهای رد شده را در کنسول چاپ خواهد کرد.
فایلی را برای بهینه‌سازی هدایت‌شده با پروفایل مشخص کنید. زیربخش AOT profiler را ببینید. برای مشخص کردن چندین فایل، گزینه profile را چندین بار درج کنید.
کامپایل AOT *فقط* برای متدهایی که در فایل‌های مشخص‌شده با گزینه profile توصیف شده‌اند. زیربخش AOT profiler را ببینید.
بازنویسی مقدار یک فیلد ایستا و فقط‌خواندنی (static readonly). معمولاً در حین کامپایل JIT، سازنده ایستا به صورت مشتاقانه (eagerly) اجرا می‌شود، بنابراین مقدار یک فیلد فقط‌خواندنی ایستا در زمان کامپایل مشخص است و کامپایلر می‌تواند بهینه‌سازی‌های متعددی بر اساس آن انجام دهد. در مقابل در حین AOT، سازنده ایستا نمی‌تواند اجرا شود، بنابراین می‌توان از این گزینه برای تنظیم مقدار چنین فیلدی و فعال‌سازی همان بهینه‌سازی‌ها استفاده کرد. نوع می‌تواند هر کدام از i1، i2، i4 برای اعداد صحیح با اندازه‌های متناظر (به بایت) باشد. توجه داشته باشید که علامت‌دار یا بدون‌علامت بودن اعداد در اینجا اهمیتی ندارد، تنها اندازه ذخیره‌سازی مهم است. این گزینه می‌تواند چندین بار مشخص شود و مانع از اجرای سازنده ایستا برای نوع تعریف‌کننده فیلد طبق قوانین معمول در زمان اجرا نمی‌شود (از این رو احتمالاً مقدار متفاوتی برای فیلد محاسبه می‌شود).
به کامپایلر AOT دستور می‌دهد تا فایل‌های موقت را نگه دارد.
به کامپایلر دستور می‌دهد تا بررسی‌های sequence point را ایجاد کند که به اشکال‌زدای نرم‌افزاری (soft debugger) مونو اجازه می‌دهد برنامه‌ها را حتی در سیستم‌هایی که در آن‌ها امکان تنظیم نقطه توقف (breakpoint) یا گام‌به‌گام رفتن (single step) وجود ندارد (پیکربندی‌های سخت‌افزاری خاص مانند تلفن‌های همراه و کنسول‌های بازی ویدیویی)، اشکال‌زدایی کند.
ایجاد یک فایل شیء ELF (با پسوند .o) یا فایل .s که در هنگام جاسازی زمان‌اجرای mono می‌تواند به صورت ایستا به یک فایل اجرایی پیوند داده شود. وقتی این گزینه استفاده می‌شود، فایل شیء باید با استفاده از تابع mono_aot_register_module در زمان‌اجرای جاسازی‌شده ثبت شود که به عنوان آرگومان، نماد سراسری mono_aot_module_<ASSEMBLY NAME>_info را از فایل شیء می‌گیرد: 
extern void *mono_aot_module_hello_info;
mono_aot_register_module (mono_aot_module_hello_info);
چاپ آمارهای مختلف جمع‌آوری شده در طول کامپایل AOT.
تعیین صریح مسیر ذخیره‌سازی فایل‌های موقت ایجاد شده در طول کامپایل AOT.
این یک گزینه آزمایشی است تا کامپایلر AOT در هنگام کامپایل متدها از چندین ریسه (thread) استفاده کند.
پیشوند <PREFIX> را به ابتدای نام ابزارهای اجرا شده توسط کامپایلر AOT، مانند 'as'/'ld' اضافه می‌کند. برای مثال، --tool=prefix=arm-linux-gnueabi- باعث می‌شود کامپایلر AOT به جای 'as'، ابزار 'arm-linux-gnueabi-as' را اجرا کند.
یکی از ابزارهای مورد استفاده برای ساخت‌های AOT، پیونددهنده (linker) است. نام آن در بین سیستم‌های مختلف متفاوت است و ممکن است نام پیش‌فرض فرض‌شده برای باینری موجود نباشد. اگر زنجیره ابزار (toolchain) مورد استفاده پیونددهنده‌ای با نام پیش‌فرض نداشته باشد (مثلاً Android NDK r22 پیونددهنده پیش‌فرض 'ld' با پیشوند 'tool-prefix' بالا را ندارد، بلکه پیونددهنده‌های با پیشوند 'ld.gold' و 'ld.bfd' دارد)، می‌توان از این گزینه برای تعیین نام باینری پیونددهنده استفاده کرد. پیشوند 'tool-prefix' به این نام اضافه خواهد شد تا نام کامل فایل اجرایی پیونددهنده تشکیل شود.
اطلاعات تکمیلی درباره خطاهای بارگذاری نوع چاپ می‌کند.
به کامپایلر AOT دستور می‌دهد تا اطلاعات نمادهای اشکال‌زدایی را منتشر کند (یا نکند).
به کامپایلر AOT دستور می‌دهد هنگام کامپایل با LLVM، ابزار opt را فراخوانی نکند.

برای اطلاعات بیشتر درباره AOT، ببینید: http://www.mono-project.com/docs/advanced/aot

فهرستی از دایرکتوری‌های اضافی برای جستجوی تصاویر AOT.
اعمال پیوندهای اسمبلی از فایل پیکربندی مشخص‌شده هنگام اجرای کامپایلر AOT. این گزینه زمانی مفید است که یک اسمبلی کمکی که توسط یک اسمبلی اصلی دارای فایل پیکربندی ارجاع داده شده، کامپایل می‌شود. برای مثال، اگر app.exe از lib.dll استفاده می‌کند، برای اینکه پیوندهای اسمبلی از app.exe.config هنگام کامپایل پیش‌هنگام lib.dll در دسترس قرار گیرد، استفاده کنید از: 
mono --apply-bindings=app.exe.config --aot lib.dll
اگر حالت strict باشد، Mono بررسی خواهد کرد که نشان کلید عمومی (public key token)، فرهنگ (culture) و نسخه اسمبلی کاندید با نام قوی درخواستی (strong name) مطابقت داشته باشد. اگر حالت legacy باشد، تا زمانی که نام مطابقت داشته باشد، کاندید مجاز خواهد بود. strict رفتاری سازگار با .NET Framework است اما ممکن است برخی از برنامه‌های موجود مبتنی بر mono را با مشکل مواجه کند. مقدار پیش‌فرض legacy است.
در حال حاضر تنها گزینه پشتیبانی‌شده توسط این آرگومان خط فرمان، disable است که قابلیت اتصال (attach) را غیرفعال می‌کند.
بارگذاری فایل پیکربندی مشخص‌شده به جای فایل(های) پیش‌فرض. فایل‌های پیش‌فرض /etc/mono/config و ‎~/.mono/config‎ یا فایل مشخص‌شده در متغیر محیطی MONO_CONFIG (در صورت تنظیم) هستند. برای جزئیات مربوط به قالب این فایل، صفحه راهنمای mono-config(5) را ببینید.
به زمان‌اجرای Mono دستور می‌دهد تا یک عامل اشکال‌زدایی (debugging agent) را در داخل زمان‌اجرای Mono راه‌اندازی کند و آن را به یک رابط کاربری کلاینت که فرایند Mono را کنترل خواهد کرد متصل کند. این گزینه معمولاً توسط IDEها مانند محیط‌های توسعه MonoDevelop یا Visual Studio استفاده می‌شود.
پیکربندی با استفاده از یک یا چند مورد از گزینه‌های زیر مشخص می‌شود:
از این گزینه برای تعیین آدرس IP استفاده کنید که کلاینت اشکال‌زدای شما به آن گوش می‌دهد..TP loglevel=LEVEL سطح ثبت وقایع تشخیصی را مشخص می‌کند برای
برای مشخص کردن فایلی که لاگ در آن ذخیره می‌شود به کار می‌رود؛ پیش‌فرض آن خروجی استاندارد است.
پیش‌فرض no است؛ با گزینهٔ پیش‌فرض، Mono به طور فعال به میزبان/درگاهی که با گزینهٔ address پیکربندی شده است متصل می‌شود. اگر آن را روی 'y' تنظیم کنید، به زمان اجرای Mono دستور می‌دهد تا اشکال‌زدایی را در حالت سرور آغاز کند، جایی که Mono به طور فعال منتظر می‌ماند تا پیشانهٔ اشکال‌زدا به فرآیند Mono متصل شود. Mono آدرس IP و درگاهی را که به آن گوش می‌دهد در stdout چاپ خواهد کرد.
اگر روی yes تنظیم شود، در صورت در دسترس بودن آن تابع روی سیستم، Mono در هنگام راه‌اندازی setpgid(0, 0) را فراخوانی می‌کند. این برای اطمینان از این است که سیگنال‌های تحویل‌داده‌شده به فرآیندی که اشکال‌زدایی‌شونده (debuggee) را اجرا می‌کند به اشکال‌زدایی‌شونده انتشار نیابند، برای نمونه هنگامی که Ctrl-C سیگنال SIGINT را به ابزار sdb ارسال می‌کند.
پیش‌فرض yes است؛ با گزینهٔ پیش‌فرض، Mono در هنگام راه‌اندازی، ماشین مجازی (vm) را تا زمانی که با موفقیت به یک پیشانهٔ اشکال‌زدا متصل شود معلق می‌کند. اگر در ترکیب با server=y آن را روی 'n' تنظیم کنید، به زمان اجرای Mono دستور می‌دهد تا به صورت عادی اجرا شود و در عین حال فراداده‌ها را ذخیره کند تا هنگام برقراری اتصال به پیشانهٔ اشکال‌زدا ارسال شوند..
برای مشخص کردن بستر انتقالی (transport) که اشکال‌زدا برای برقراری ارتباط استفاده می‌کند به کار می‌رود. این مقدار حتماً باید مشخص شود و در حال حاضر لازم است که
ماشین مجازی را به گونه‌ای پیکربندی می‌کند که برای برنامه‌های رومیزی (desktop) مناسب‌تر باشد. در حال حاضر این گزینه سیستم GC را به گونه‌ای تنظیم می‌کند که تا جای ممکن از گسترش heap جلوگیری کند، البته به بهای اینکه بازیافت حافظه (garbage collection) اندکی کُندتر شود.
این پرچم به زمان اجرای Mono دستور می‌دهد که در زمان اجرا هیچ کدی تولید نکند و منحصراً به کدهایی وابسته باشد که قبلاً با استفاده از mono --aot=full تولید شده‌اند. این ویژگی برای پلتفرم‌هایی که اجازهٔ تولید کد پویا را نمی‌دهند، یا در صورتی که نیاز به اجرای اسمبلی‌هایی داشته باشید که کدهای IL آن‌ها حذف شده است (برای نمونه با استفاده از mono-cil-strip) مفید است. توجه داشته باشید که اگر مسیری از کد در برنامهٔ شما یا کتابخانه‌های کلاس Mono تلاش کند کدی را به صورت پویا تولید کند، این ویژگی اجرای برنامه را در زمان اجرا متوقف (abort) خواهد کرد. شما باید نرم‌افزار خود را از قبل آزمایش کنید و مطمئن شوید که از هیچ قابلیت پویایی استفاده نمی‌کنید.
مشابه --full-aot همراه با بازگشت (fallback) به مفسر.
موتور بازیافت حافظه (Garbage Collector) را برای استفاده توسط Mono انتخاب می‌کند: Boehm یا SGen. در حال حاضر این گزینه صرفاً تضمین می‌کند که یکی از دستورهای mono یا mono-sgen را اجرا می‌کنید. این پرچم را می‌توان در متغیر محیطی MONO_ENV_OPTIONS تنظیم کرد تا تمام فرآیندهای فرزند شما را وادار به استفاده از نوع خاصی از GC با زمان اجرای Mono کند.
معادل خط فرمانیِ متغیر محیطی MONO_GC_DEBUG.
معادل خط فرمانیِ متغیر محیطی MONO_GC_PARAMS.
(تنها در Mac OS X): عرض بیتی (bitness) باینری Mono مورد استفاده را در صورت در دسترس بودن انتخاب می‌کند. اگر باینری استفاده‌شده از قبل برای همان عرض بیتی انتخاب‌شده باشد، چیزی تغییر نمی‌کند. در غیر این صورت، اجرا به باینری با پسوند عرض بیتی انتخاب‌شده که در کنار آن نصب شده سوئیچ می‌کند (برای نمونه، '/bin/mono --arch=64' به '/bin/mono64' سوئیچ خواهد کرد اگر و تنها اگر '/bin/mono' یک بیلد ۳۲ بیتی باشد).
دستورالعمل‌های نحوهٔ استفاده را نمایش می‌دهد.
زمان اجرای Mono از مفسر خود برای اجرای اسمبلی داده‌شده استفاده خواهد کرد. مفسر معمولاً از JIT کُندتر است، اما در پلتفرم‌هایی که تولید کد در زمان اجرا مجاز نیست، می‌تواند مفید باشد.
این پرچم به زمان اجرای Mono اجازه می‌دهد اسمبلی‌هایی را که کدهای IL آن‌ها حذف شده است اجرا کند، برای نمونه با استفاده از mono-cil-strip. برای اینکه این ویژگی کار کند، اسمبلی باید با --aot=hybrid به صورت AOT کامپایل شده باشد. این پرچم مشابه --full-aot است، اما JIT را غیرفعال نمی‌کند. این بدان معناست که می‌توانید از قابلیت‌های پویا مانند System.Reflection.Emit استفاده کنید.
--llvm
اگر زمان اجرای Mono با پشتیبانی از LLVM کامپایل شده باشد (در همهٔ پیکربندی‌ها موجود نیست)، Mono از موتور بهینه‌سازی و تولید کد LLVM برای کامپایل JIT یا AOT استفاده خواهد کرد. برای اطلاعات بیشتر، ببینید: http://www.mono-project.com/docs/advanced/mono-llvm
این پرچم به Mono و LLVM اجازه می‌دهد بهینه‌سازی‌های ممیز شناور تهاجمی را اعمال کنند. می‌تواند سازگاری با IEEE754 را بشکند.
هنگام استفاده از Monoای که با پشتیبانی LLVM کامپایل شده است، Mono را وادار می‌کند به موتور JIT خود بازگردد (fallback) و از backend مربوط به LLVM استفاده نکند.
مقدار MODE فهرستی از بهینه‌سازی‌ها است که با ویرگول از هم جدا شده‌اند. همچنین می‌توان با قرار دادن یک علامت منفی پیش از نام بهینه‌سازی، آن را غیرفعال کرد. به طور کلی، Mono طوری تنظیم شده است که از مجموعه پرچم‌های پیش‌فرض استفاده کند؛ پیش از استفاده از این پرچم‌ها برای یک محیط استقرار (deployment)، شاید بهتر باشد مزایای استفاده از آن‌ها را عملاً بسنجید. پرچم‌های بهینه‌سازی زیر در موتور اصلی پیاده‌سازی شده‌اند: 
abcrem     حذف بررسی‌های محدوده آرایه
all        فعال کردن تمام بهینه‌سازی‌ها
aot        استفاده از کد کامپایل‌شده پیش از زمان (Ahead Of Time)
branch     بهینه‌سازی‌های انشعاب
cfold      محاسبه مقادیر ثابت در زمان کامپایل (Constant folding)
cmov       انتقال‌های شرطی [arch-dependency]
deadce     حذف کدهای مرده (Dead code elimination)
consprop   انتشار مقادیر ثابت (Constant propagation)
copyprop   انتشار رونوشت (Copy propagation)
fcmov      مقایسه‌های ممیز شناور سریع در x86 [arch-dependency]
float32	انجام محاسبات ممیز شناور ۳۲ بیتی با استفاده از عملیات‌های ۳۲ بیتی
gshared    فعال‌سازی اشتراک‌گذاری کد جنریک
inline     درون‌خطی‌سازی فراخوانی متدها
intrins    پیاده‌سازی‌های ذاتی متدها (Intrinsic)
linears    تخصیص سراسری ثبات با پیمایش خطی
leaf       بهینه‌سازی‌های توابع برگ (Leaf)
loop       بهینه‌سازی‌های مربوط به حلقه
peephole   گام نهایی بهینه‌سازی روزنه‌ای (Peephole)
precomp    پیش‌کامپایل تمام متدها پیش از اجرای Main
sched      زمان‌بندی دستورالعمل‌ها
shared     تولید کد به ازای هر دامنه (per-domain)
sse2       دستورالعمل‌های SSE2 در x86 [arch-dependency]
tailc      بازگشت دم و فراخوانی‌های دم (Tail calls)
برای نمونه، جهت فعال‌سازی تمام بهینه‌سازی‌ها به جز حذف کدهای مرده و درون‌خطی‌سازی، می‌توانید از این دستور استفاده کنید: 
-O=all,-deadce,-inline
پرچم‌هایی که با [arch-dependency] علامت‌گذاری شده‌اند نشان می‌دهند که اگر گزینهٔ مربوطه در ترکیب با کامپایل پیش از زمان (پرچم --aot) استفاده شود، کدی پیش‌کامپایل‌شده تولید خواهد کرد که به پردازندهٔ (CPU) فعلی وابسته است و ممکن است نتوان آن را با اطمینان به رایانهٔ دیگری منتقل کرد.

بهینه‌سازی‌های زیر پشتیبانی می‌شوند

درخواست می‌کند که زمان اجرا، محاسبات ممیز شناور ۳۲ بیتی را تنها با استفاده از ۳۲ بیت انجام دهد. به طور پیش‌فرض، زمان اجرای Mono تلاش می‌کند از بالاترین دقت موجود برای محاسبات ممیز شناور استفاده کند؛ هرچند این کار ممکن است نتایج بهتری به همراه داشته باشد، اما کد ممکن است کُندتر اجرا شود. این گزینه همچنین روی کد تولیدشده توسط backend مربوط به LLVM تأثیر می‌گذارد.
کنترل می‌کند که آیا زمان اجرا باید فراخوانی‌های متد را درون‌خطی (inline) کند (حالت پیش‌فرض) یا خیر
--response=FILE یک فایل پاسخ (response file) ارائه می‌دهد؛ این گزینه به دستور Mono اعلام می‌کند که سایر گزینه‌های خط فرمان را از فایل مشخص‌شده بخواند، درست مانند اینکه گزینه‌ها در خود خط فرمان مشخص شده باشند. این گزینه زمانی که خطوط فرمان بسیار طولانی دارید مفید است.
Mono از نسخه‌های مختلف زمان اجرا (runtime) پشتیبانی می‌کند. نسخهٔ مورد استفاده به برنامه‌ای که در حال اجراست یا فایل پیکربندی آن (به نام program.exe.config) بستگی دارد. از این گزینه می‌توان برای نادیده‌گرفتن این تشخیص خودکار، با اجبار به استفاده از یک نسخهٔ متفاوت زمان اجرا، استفاده کرد. توجه داشته باشید که این گزینه فقط باید برای انتخاب نسخهٔ سازگار متأخرتری نسبت به نسخه‌ای که برنامه با آن کامپایل شده است استفاده شود. یک کاربرد رایج، اجرای یک برنامهٔ نسخهٔ 1.1 روی نسخهٔ 2.0 است:.nf
mono --runtime=v2.0.50727 program.exe
ماشین مجازی را به‌گونه‌ای پیکربندی می‌کند که برای عملیات سرور مناسب‌تر باشد (در حال حاضر، مقداردهی اولیه سنگین‌تری برای threadpool مجاز می‌کند).
به Mono دستور می‌دهد تا با استفاده از MAP_JIT در MacOS کد تولید کند. برای برنامه‌های بسته‌بندی‌شده (bundled) ضروری است.
فایل mscorlib و اسمبلی‌های موجود در حافظه پنهان سراسری اسمبلی (global assembly cache) را برای IL معتبر، و تمام کدهای کاربر را برای قابلیت اعتبارسنجی IL بررسی می‌کند.

این گزینه با گزینه‌های verifiable یا validil در --security متفاوت است؛ زیرا آن گزینه‌ها تنها کد کاربر را بررسی کرده و از mscorlib و اسمبلی‌های واقع در global assembly cache صرف‌نظر می‌کنند.

اطلاعات نسخه JIT را چاپ می‌کند (پیکربندی سیستم، شماره انتشار و نام شاخه‌ها در صورت موجود بودن).
تنها شماره نسخه را چاپ می‌کند.

گزینه‌های زیر برای کمک در هنگام توسعه یک برنامه JIT به کار می‌روند.

حالت اشکال‌زدایی را در زمان اجرا فعال می‌کند. اگر یک اسمبلی با اطلاعات اشکال‌زدایی کامپایل شده باشد، اطلاعات شماره خط را برای ردگیری‌های پشته (stack traces) تولید خواهد کرد.

آرگومان اختیاری OPTIONS فهرستی از گزینه‌های اشکال‌زدایی است که با کاما از هم جدا شده‌اند. این گزینه‌ها به‌طور پیش‌فرض غیرفعال هستند زیرا در زمان اجرا کدهای بسیار بزرگ‌تر و کندتری تولید می‌کنند.

گزینه‌های زیر پشتیبانی می‌شوند:
هنگام پرتاب InvalidCastException یک خطای دقیق تولید می‌کند. این گزینه باید فعال شود چرا که در زمان اجرا کدهای پرحجم‌تری تولید می‌کند.
برخی بهینه‌سازی‌های JIT را که معمولاً فقط هنگام اجرا درون اشکال‌زدا غیرفعال هستند، غیرفعال می‌کند. این ویژگی در صورتی که بخواهید با mdb به فرایند در حال اجرا متصل شوید می‌تواند مفید باشد.
اطلاعات اشکال‌زدایی را با gdb تولید و ثبت می‌کند. این قابلیت تنها در برخی پلتفرم‌ها و تنها هنگام استفاده از gdb 7.0 یا بالاتر پشتیبانی می‌شود.
یک ماژول پروفایلر را با آرگومان‌های داده‌شده بارگذاری می‌کند. برای اطلاعات بیشتر، بخش PROFILING را ببینید. از این گزینه می‌توان چندین بار استفاده کرد؛ هر بار یک ماژول پروفایلر اضافی بارگذاری خواهد شد.
نام متدها را هنگام فراخوانی نمایش می‌دهد. به‌طور پیش‌فرض تمام متدها ردگیری می‌شوند. ردگیری را می‌توان برای شامل کردن یا مستثنی کردن متدها، کلاس‌ها یا اسمبلی‌ها سفارشی‌سازی کرد. عبارت trace فهرستی از هدف‌ها است که با کاما از هم جدا شده‌اند؛ هر هدف می‌تواند با یک علامت منفی پیشوند شود تا هدف مشخصی خاموش شود. کلمات `program`،‏ `all` و `disabled` معنای ویژه‌ای دارند. کلمه `program` به برنامه اصلی در حال اجرا اشاره دارد و `all` به معنای تمام فراخوانی‌های متد است. گزینه `disabled` برای شروع با ردگیری غیرفعال استفاده می‌شود. می‌توان آن را در زمان دیگری در طول برنامه با ارسال سیگنال SIGUSR2 به runtime فعال کرد. اسمبلی‌ها با نامشان مشخص می‌شوند؛ برای نمونه، جهت ردگیری تمام فراخوانی‌ها در اسمبلی System، استفاده کنید از: 
mono --trace=System app.exe
کلاس‌ها با پیشوند :T مشخص می‌شوند. برای نمونه، جهت ردگیری تمام فراخوانی‌ها به کلاس System.String، استفاده کنید از: 
mono --trace=T:System.String app.exe
و متدهای تکی با پیشوند :M و نشانه‌گذاری استاندارد متد مشخص می‌شوند: 
mono --trace=M:System.Console:WriteLine app.exe
استثناها نیز می‌توانند ردگیری شوند، که موجب می‌شود هر بار که استثنایی از نوع مشخص‌شده پرتاب شود، یک stack trace چاپ گردد. نوع استثنا می‌تواند با یا بدون namespace مشخص شود، و برای ردگیری تمام استثناها، 'all' را به عنوان نام نوع مشخص کنید. 
mono --trace=E:System.Exception app.exe
همان‌طور که قبلاً ذکر شد، می‌توان چندین قاعده را به طور همزمان مشخص کرد: 
mono --trace=T:System.String,T:System.Random app.exe
می‌توانید بخش‌هایی را مستثنی کنید؛ مثال بعدی فراخوانی‌ها به System.String را به جز متد System.String:Concat ردگیری می‌کند: 
mono --trace=T:System.String,-M:System.String:Concat
می‌توانید گذارها از کد مدیریت‌شده به مدیریت‌نشده را با استفاده از مشخص‌کننده wrapper ردگیری کنید: 
mono --trace=wrapper app.exe
در نهایت، فضاهای نام را می‌توان با استفاده از پیشوند :N مشخص کرد: 
mono --trace=N:System.Xml
فریم‌های پشته را در معماری x86 تراز نمی‌کند. به‌طور پیش‌فرض، Mono فریم‌های پشته را در x86 روی ۱۶ بایت تراز می‌کند تا متغیرهای محلی ممیز شناور و SIMD بتوانند به درستی تراز شوند. این گزینه ترازسازی را غیرفعال می‌کند، که معمولاً موجب صرفه‌جویی در یک دستورالعمل در هر فراخوانی می‌شود، اما ممکن است به افت چشمگیر عملکرد ممیز شناور و SIMD بینجامد.
یک نگاشت متد JIT را در یک فایل /tmp/perf-PID.map تولید می‌کند. این فایل سپس برای مثال توسط ابزار perf موجود در هسته‌های اخیر لینوکس استفاده می‌شود. هر خط در فایل شامل موارد زیر است: 
HEXADDR HEXSIZE methodname
در حال حاضر این گزینه تنها در لینوکس پشتیبانی می‌شود..SH "گزینه‌های نگه‌دارنده JIT (JIT MAINTAINER OPTIONS)" گزینه‌های نگه‌دارنده تنها توسط توسعه‌دهندگان خود محیط زمان اجرا (runtime) استفاده می‌شوند و معمولاً مورد توجه کاربران یا توسعه‌دهندگان برنامه‌ها نیستند.
این پرچم توسط خطایاب خودکار بهینه‌سازی (bug bisector) استفاده می‌شود. این گزینه یک پرچم بهینه‌سازی و نام فایلی حاوی فهرستی از نام کامل متدها (یک متد در هر خط) را دریافت می‌کند. هنگام کامپایل یکی از متدهای موجود در فایل، علاوه بر بهینه‌سازی‌های فعال دیگر، از بهینه‌سازی مشخص‌شده نیز استفاده خواهد شد. توجه داشته باشید که اگر بهینه‌سازی به‌صورت پیش‌فرض فعال باشد، باید آن را با `-O` غیرفعال کنید؛ در غیر این صورت صرف‌نظر از این‌که متد در فایل باشد یا خیر، بر روی تمامی متدها اعمال خواهد شد.
یک نقطه توقف (breakpoint) پیش از متدی با نام `method` (به‌صورت namespace.class:methodname) درج می‌کند. برای قرار دادن نقطه توقف روی متد اصلی برنامه، از `Main` به عنوان نام متد استفاده کنید. همچنین می‌توانید آن را برای Genericها نیز به کار ببرید؛ برای نمونه "System.Collections.Generic.Queue`1:Peek".
یک نقطه توقف (breakpoint) روی استثناها درج می‌کند. این امکان را به شما می‌دهد تا هنگام پرتاب شدن یک استثنا، برنامه خود را با یک دیباگر محلی (native) عیب‌یابی کنید.
یک متد (namespace.name:methodname) را کامپایل می‌کند؛ این گزینه برای سنجش کارایی کامپایلر یا بررسی خروجی تولیدکننده کد (code generator) استفاده می‌شود.
تمام متدهای موجود در یک اسمبلی (assembly) را کامپایل می‌کند. این گزینه برای ارزیابی کارایی کامپایلر یا بررسی خروجی تولیدکننده کد به کار می‌رود.
یک فایل postscript حاوی گرافی با جزئیات متد مشخص‌شده (namespace.name:methodname) تولید می‌کند. این گزینه نیازمند نصب بودن `dot` و ghostview است (انتظار می‌رود Ghostview با نام "gv" در دسترس باشد). گراف‌های زیر در دسترس هستند: 
cfg        گراف جریان کنترل (CFG)
dtree      درخت تسلط (Dominator Tree)
code       CFG نمایش‌دهنده کد
ssa        CFG نمایش‌دهنده کد پس از تبدیل SSA
optcode    CFG نمایش‌دهنده کد پس از بهینه‌سازی‌های IR
برخی از گراف‌ها تنها در صورتی در دسترس خواهند بود که بهینه‌سازی‌های خاصی فعال شده باشند.
تعداد دفعاتی که متد مشخص‌شده توسط --compile (یا تمام متدها در صورت استفاده از --compile-all) باید کامپایل شود را به محیط زمان اجرا اعلام می‌کند. این گزینه برای آزمایش کارایی تولیدکننده کد استفاده می‌شود.
اطلاعاتی درباره عملیات انجام‌شده توسط محیط زمان اجرا در طول اجرای یک برنامه را نمایش می‌دهد. اگر متدی (namespace.name:methodname) مشخص شده باشد، علاوه بر پایان اجرای برنامه، در نخستین اجرای متد نیز این اطلاعات نمایش داده خواهد شد.
عملیات نگه‌داری داده‌های اشتراکی فرایند را انجام می‌دهد. مقدار semdel سمافور سراسری (global semaphore) را حذف می‌کند. مقدار hps فهرستی از دستگیره‌های (handles) در حال استفاده فعلی را نمایش می‌دهد.
سطح پرگویی (verbosity) را افزایش می‌دهد؛ هر بار که درج شود، سطح پرگویی را برای گنجاندن اطلاعات بیشتر (شامل، برای نمونه، دیس‌اسمبلی کد محلی تولیدشده، اطلاعات گزینش‌گر کد و غیره) افزایش می‌دهد.

محیط زمان اجرای Mono به فرایندهای خارجی اجازه می‌دهد به یک فرایند در حال اجرا متصل شوند و اسمبلی‌ها را در برنامه در حال اجرا بارگذاری کنند. برای اتصال به فرایند، پروتکل ویژه‌ای در اسمبلی Mono.Management پیاده‌سازی شده است.

با این پشتیبانی، بارگذاری و اجرای اسمبلی‌هایی که دارای نقطه ورود (entry point) هستند (آن‌هایی که با -target:exe یا -target:winexe ایجاد شده‌اند) در فرایند Mono امکان‌پذیر می‌شود.

کد درون دامنه ریشه (root domain) بارگذاری می‌شود و اجرای آن روی ریسه (thread) ویژه اتصال زمان اجرا آغاز می‌گردد. برنامه متصل‌شده باید ریسه‌های خود را ایجاد کرده و پس از فراخوانی بازگردد.

این قابلیت، برای نمونه، امکان عیب‌یابی برنامه‌ها را از طریق اتصال پوسته csharp به فرایندهای در حال اجرا فراهم می‌سازد..SH "پروفایل‌سازی (PROFILING)" زمان‌اجرای Mono شامل یک API پروفایلر است که ماژول‌های بارگذاری‌شده به‌صورت پویای پروفایلر و تعبیه‌کنندگان (embedders) می‌توانند برای جمع‌آوری داده‌های مربوط به کارایی یک برنامه از آن استفاده کنند. ماژول‌های پروفایلر با ارسال آرگومان خط فرمان --profile به زمان‌اجرای Mono بارگذاری می‌شوند.

Mono همراه با چند ماژول پروفایلر عرضه می‌شود که در میان آن‌ها، پروفایلر log دارای بیشترین قابلیت‌ها است. همچنین اگر آرگومان profiler داده نشود یا اگر default مشخص شود، این پروفایلر، پروفایلر پیش‌فرض خواهد بود. نوشتن ماژول‌های پروفایلر سفارشی توسط خودتان نیز امکان‌پذیر است؛ زیربخش Custom profilers را ببینید.

پروفایلر log می‌تواند برای جمع‌آوری اطلاعات زیادی درباره برنامه‌ای که در زمان‌اجرای Mono اجرا می‌شود، استفاده شود. این داده‌ها می‌توانند (هم در حین اجرای فرایند و هم پس از آن) برای تحلیل رفتار برنامه، تعیین میزان مصرف منابع، بررسی مسائل کارایی یا حتی یافتن الگوهای اجرایی خاص مورد استفاده قرار گیرند.

این کار با ثبت وقایع ارائه‌شده توسط زمان‌اجرای Mono از طریق API پروفایلر و نوشتن دوره‌ای آن‌ها در فایلی انجام می‌شود که بعداً می‌تواند با ابزار mprof-report(1) بررسی و تحلیل شود.

اطلاعات بیشتر درباره نحوه استفاده از پروفایلر log در صفحه mono-profilers(1)، ذیل بخش LOG PROFILER و همچنین در صفحه mprof-report(1) موجود است.

پروفایلر پوشش کد (code coverage) می‌تواند برنامه را ابزاربندی (instrument) کند تا مشخص شود کدام کلاس‌ها، متدها، مسیرهای کد و غیره واقعاً اجرا شده‌اند. این ابزار هنگامی که مجموعه‌آزمونی اجرا می‌شود تا مشخص شود آیا آزمون‌ها کدی را که انتظار می‌رود واقعاً پوشش می‌دهند یا خیر، بیشترین کاربرد را دارد.

اطلاعات بیشتر درباره نحوه استفاده از پروفایلر coverage در صفحه mono-profilers(1)، ذیل بخش COVERAGE PROFILER موجود است.

پروفایلر AOT می‌تواند با ثبت اینکه کدام نمونه‌سازی‌های جنریک توسط برنامه استفاده می‌شوند، به بهبود کارایی زمان راه‌اندازی کمک کند؛ کامپایلر AOT سپس می‌تواند از این اطلاعات برای کامپایل پیش‌هنگام (ahead of time) آن نمونه‌سازی‌ها استفاده کند تا در زمان راه‌اندازی نیازی به کامپایل درجا (JIT) آن‌ها نباشد.

اطلاعات بیشتر درباره نحوه استفاده از پروفایلر AOT در صفحه mono-profilers(1)، ذیل بخش AOT PROFILER موجود است.

ماژول‌های پروفایلر سفارشی می‌توانند دقیقاً به همان روش ماژول‌های استانداردی که همراه با Mono عرضه می‌شوند بارگذاری گردند. آن‌ها همچنین می‌توانند به همان API پروفایلر دسترسی داشته باشند تا انواع اطلاعات را درباره کدی که در حال اجرا است جمع‌آوری کنند.

به عنوان مثال، برای استفاده از یک پروفایلر شخص ثالث با نام custom، آن را به این صورت بارگذاری می‌کنید:

mono --profile=custom program.exe

همچنین می‌توانید آرگومان‌هایی به آن ارسال کنید:

mono --profile=custom:arg1,arg2=arg3 program.exe

در مثال بالا، Mono پروفایلر را از کتابخانه اشتراکی با نام libmono-profiler-custom.so بارگذاری خواهد کرد (نام بر اساس پلتفرم متفاوت است، مثلاً libmono-profiler-custom.dylib در OS X). این ماژول پروفایلر باید در مسیر کتابخانه‌های پیونددهنده پویای شما قرار داشته باشد (LD_LIBRARY_PATH در اکثر سیستم‌ها، DYLD_LIBRARY_PATH در OS X).

برای مشاهده نمونه‌ای از نحوه نوشتن پروفایلر سفارشی خودتان، فایل samples/profiler/sample.c را در درخت کد منبع Mono ببینید.

برای اشکال‌زدایی برنامه‌های مدیریت‌شده (managed)، می‌توانید از دستور mdb که یک اشکال‌زدای خط فرمان است استفاده کنید.

دریافت یک ردپای پشته (stack trace) از تمامی رشته‌های فعال در Mono با ارسال سیگنال QUIT به Mono امکان‌پذیر است؛ می‌توانید این کار را از خط فرمان به این صورت انجام دهید:

kill -QUIT pid
که در آن pid شناسه فرایند (Process ID) مربوط به فرایند Mono است که می‌خواهید آن را بررسی کنید. فرایند پس از آن به اجرای خود ادامه خواهد داد، اما وضعیت آن تضمین‌شده نیست.

مهم: این یک سازوکار آخرین چاره برای اشکال‌زدایی برنامه‌هاست و نباید برای نظارت یا کاوش یک برنامه در محیط عملیاتی استفاده شود. یکپارچگی زمان‌اجرا پس از ارسال این سیگنال تضمین نمی‌شود و ممکن است برنامه در هر لحظه پس از آن دچار فروپاشی (crash) یا خاتمه شود.

گزینه --debug=casts می‌تواند برای دریافت اطلاعات دقیق‌تر درباره عملیات‌های تبدیل نامعتبر (Invalid Cast) استفاده شود؛ این گزینه اطلاعاتی را درباره نوع‌های (types) درگیر فراهم می‌آورد.

می‌توانید از متغیرهای محیطی MONO_LOG_LEVEL و MONO_LOG_MASK برای دریافت خروجی اشکال‌زدایی پرجزئیات درباره اجرای برنامه خود در Mono استفاده کنید.

متغیر محیطی MONO_LOG_LEVEL در صورت تنظیم، سطح ثبت وقایع را به مقدار تعیین‌شده تغییر می‌دهد. مقادیر ممکن عبارتند از "error"، "critical"، "warning"، "message"، "info"، "debug". مقدار پیش‌فرض "error" است. پیام‌هایی با سطح ثبت وقایع بزرگ‌تر یا مساوی با سطح تعیین‌شده در stdout/stderr چاپ خواهند شد.

برای ردیابی بارگذاری پویای اسمبلی‌ها از "info" استفاده کنید.

از متغیر محیطی MONO_LOG_MASK برای محدود کردن دامنه پیام‌های دریافتی استفاده کنید: در صورت تنظیم، ماسک لاگ به مقدار تعیین‌شده تغییر می‌یابد. مقادیر ممکن عبارتند از: "asm" (بارگذار اسمبلی)، "type"، "dll" (بارگذار کتابخانه محلی)، "gc" (زباله‌روب)، "cfg" (بارگذار فایل پیکربندی)، "aot" (پیش‌کامپایلر)، "security" (مثلاً پشتیبانی Moonlight CoreCLR)، "threadpool" (استخر رشته عمومی)، "io-selector" (عملیات‌های ناهمگام سوکت)، "io-layer" (لایه I/O - فرایندها، فایل‌ها، سوکت‌ها، رویدادها، سمافورها، میوتکس‌ها و دستگیره‌ها)، "io-layer-process"، "io-layer-file"، "io-layer-socket"، "io-layer-event"، "io-layer-semaphore"، "io-layer-mutex"، "io-layer-handle" و "all". مقدار پیش‌فرض "all" است. تغییر مقدار ماسک به شما اجازه می‌دهد تنها پیام‌های مربوط به یک مؤلفه خاص را نمایش دهید. می‌توانید با جدا کردن چندین ماسک با کاما، از آن‌ها به صورت همزمان استفاده کنید. برای مثال جهت مشاهده پیام‌های فایل پیکربندی و پیام‌های بارگذار اسمبلی، ماسک خود را روی "asm,cfg" تنظیم کنید.

مورد زیر یک کاربرد متداول برای ردیابی و یافتن مشکلات مربوط به P/Invoke است:

$ MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" mono glue.exe
اگر از LLDB استفاده می‌کنید، می‌توانید از اسکریپت mono.py برای چاپ برخی از ساختارهای داده داخلی با آن استفاده کنید. برای استفاده از این قابلیت، عبارت زیر را به فایل $HOME/.lldbinit خود اضافه کنید: 
command script import $PREFIX/lib/mono/lldb/mono.py

که در آن $PREFIX همان مقدار پیشوندی است که هنگام پیکربندی Mono مشخص کرده‌اید (معمولاً /usr).

پس از انجام این کار، می‌توانید برخی از ساختارهای داده Mono Runtime را بررسی کنید؛ برای مثال:

(lldb) p method
(MonoMethod *) $0 = 0x05026ac0 [mscorlib]System.OutOfMemoryException:.ctor()

موتور سریال‌سازی XML در Mono به‌طور پیش‌فرض از رویکردی مبتنی بر بازتاب (reflection) برای سریال‌سازی استفاده می‌کند که ممکن است برای پردازش‌های مداوم (برنامه‌های کاربردی وب‌سرویس) کُند باشد. موتور سریال‌سازی بر اساس چند پارامتر تعیین می‌کند که چه زمانی یک کلاس باید از یک سریال‌ساز بهینه‌سازی‌شده دستی استفاده کند و در صورت نیاز، در زمان اجرا یک سریال‌ساز سفارشی C# برای انواع داده‌های شما تولید خواهد کرد. سپس این سریال‌ساز سفارشی به‌صورت پویا در برنامه کاربردی شما بارگذاری می‌شود.

می‌توانید این رفتار را با استفاده از متغیر محیطی MONO_XMLSERIALIZER_THS کنترل کنید.

مقادیر معتبر عبارتند از `no' برای غیرفعال کردن استفاده از سریال‌ساز سفارشی C#، یا یک عدد صحیح که بیانگر حداقل تعداد دفعات استفاده پیش از تولید یک سریال‌ساز سفارشی توسط زمان اجرا است (۰ در نخستین دسترسی یک سریال‌ساز سفارشی تولید می‌کند، ۵۰ در پنجاهمین استفاده اقدام به تولید آن می‌نماید). اگر به هر دلیلی تولید سریال‌ساز با شکست مواجه شود، Mono به یک سریال‌ساز تفسیری بازگشت (fallback) خواهد کرد. این رفتار را می‌توان با تنظیم گزینه `nofallback' غیرفعال کرد (برای مثال: MONO_XMLSERIALIZER_THS=0,nofallback).

فرایند زباله‌روبی (garbage collection) را در Mono غیرفعال می‌کند. این مورد فقط باید برای مقاصد عیب‌یابی استفاده شود.
(همچنین http_proxy) در صورت تنظیم، درخواست‌های وبی که از کتابخانه کلاس Mono استفاده می‌کنند به‌طور خودکار از طریق URL مشخص‌شده هدایت می‌شوند. در سیستم‌عامل‌های Windows، Mac OS، iOS یا Android پشتیبانی نمی‌شود. همچنین ببینید: NO_PROXY.
هنگامی که Mono با پشتیبانی از LLVM کامپایل شده باشد، این متغیر به زمان اجرا دستور می‌دهد که پس از JIT شدن تعداد مشخصی از متدها، استفاده از LLVM را متوقف کند. این ابزاری تشخیصی است که برای تفکیک و ریشه‌یابی مشکلات در بخش تولید کد (backend) کاربرد دارد. برای مثال، LLVM_COUNT=10 تنها ۱۰ متد را با LLVM کامپایل کرده و سپس به موتور JIT خود Mono سوئیچ می‌کند. مقدار LLVM_COUNT=0 موتور LLVM را به‌طور کامل غیرفعال می‌سازد.
مونو شامل قابلیتی است که با استفاده از نگاشت‌کننده‌های بخش پیکربندی (config section mappers)، امکان ویرایش تنظیمات در فایل‌های .config ارائه‌شده همراه با Mono را فراهم می‌کند. نگاشت‌کننده‌ها و قوانین نگاشت در فایل $prefix/etc/mono/2.0/settings.map و به‌صورت اختیاری در فایل settings.map موجود در دایرکتوری اصلی برنامه ASP.NET شما تعریف شده‌اند. در صورت وجود، هر دو فایل هنگام راه‌اندازی برنامه توسط System.Web خوانده می‌شوند. اگر نمی‌خواهید فرایند نگاشت انجام شود، می‌توانید پیش از اجرای برنامه این متغیر را در محیط خود تنظیم کنید تا هیچ اقدامی انجام نگیرد.
مونو از یک حافظه موقت (کش) برای اشیاء ConfigSection جهت سرعت بخشیدن به پرس‌وجوهای WebConfigurationManager بهره می‌برد. اندازه پیش‌فرض آن ۱۰۰ مورد است و زمانی که به موارد بیشتری نیاز باشد، حذف اقلام قدیمی از حافظه پنهان (cache eviction) آغاز می‌شود. اگر دفعات حذف بیش از حد باشد، بار کاری غیرضروری تحمیل خواهد شد که می‌توان با استفاده از این متغیر محیطی اندازه حافظه پنهان را افزایش داد (یا با کاهش آن، میزان مصرف حافظه را کمتر کرد).
در صورت تنظیم، باعث می‌شود Mono.Cairo در هنگام تخصیص اشیاء اقدام به جمع‌آوری ردیابی پشته (stack trace) نماید تا هشدارهای finalization/Dispose حاوی اطلاعاتی درباره مبدأ ایجاد نمونه مربوطه باشند.
در صورت تنظیم، این متغیر جایگزین دایرکتوری پیش‌فرض پیکربندی سیستم ($PREFIX/etc) می‌شود. از این متغیر برای تعیین مسیر فایل machine.config استفاده می‌گردد.
سبک تعامل COM (یا COM interop) را مشخص می‌کند. اگر مقدار این متغیر "MS" باشد، Mono از روتین‌های مرتب‌سازی رشته‌ای (string marshalling) کتابخانه liboleaut32 برای نوع BSTR استفاده می‌کند؛ هر مقدار دیگری موجب استفاده از سازوکار داخلی mono برای مرتب‌سازی رشته‌های BSTR خواهد شد.
در صورت تنظیم، این متغیر جایگزین فایل پیش‌فرض پیکربندی زمان اجرا ($PREFIX/etc/mono/config) می‌شود. گزینه خط فرمان --config بر این متغیر محیطی اولویت دارد.
سازوکار شناسایی خودکار پردازنده را بازنویسی می‌کند. در حال حاضر فقط روی معماری arm کاربرد دارد. ساختار مقدار آن به شرح زیر است: 
"armvV [thumb[2]]"
که در آن V شماره معماری (۴، ۵، ۶، ۷) بوده و گزینه‌ها در حال حاضر می‌توانند "thumb" یا "thumb2" باشند. مثال: 
MONO_CPU_ARCH="armv4 thumb" mono ...
هنگامی که Mono با امکان بازگشت به ممیز شناور نرم‌افزاری (soft float fallback) روی ARM ساخته شده باشد و این متغیر روی "1" تنظیم شود، Mono همواره کد ممیز شناور نرم‌افزاری تولید خواهد کرد، حتی اگر یک واحد سخت‌افزاری VFP شناسایی گردد.
بازگشت به پیاده‌سازی kqueue برای FileSystemWatcher در سیستم‌عامل Darwin. پیاده‌سازی پیش‌فرض مبتنی بر FSEvent است.
این یک گزینه کمکی برای عیب‌یابی است که جهت اعمال محدودیت بر پیاده‌سازی kqueue برای FileSystemWatcher در سیستم‌عامل Darwin استفاده می‌شود. به‌طور پیش‌فرض هیچ محدودیتی وجود ندارد.
اگر مقدار این متغیر محیطی برابر با `yes' باشد، زمان اجرا از تطبیق و مقایسه (collation) مدیریت‌نشده استفاده می‌کند (که در واقع به معنای عدم اعمال مقایسه وابسته به فرهنگ/زبان است). این متغیر عملکرد تطبیق مدیریت‌شده را که از طریق اعضای کلاس System.Globalization.CompareInfo فراخوانی می‌شود، به‌طور داخلی غیرفعال می‌سازد. تطبیق به‌طور پیش‌فرض فعال است.
فقط در Unix: در صورت تنظیم، استفاده از حافظه اشتراکی را برای ارائه شمارنده‌های کارایی (performance counters) غیرفعال می‌کند. این بدان معناست که نه خواندن شمارنده‌های کارایی این فرایند توسط برنامه‌های دیگر امکان‌پذیر خواهد بود و نه خواندن شمارنده‌های فرایندهای خارجی توسط این برنامه.
در صورت تنظیم، استفاده از تحلیل‌گر DNS کاملاً مدیریت‌شده را به‌جای توابع استاندارد libc فعال می‌سازد. این تحلیل‌گر هنگام اجرای موازی چندین پرس‌وجو عملکرد بسیار بهتری نشان می‌دهد.

توجه داشته باشید که در این حالت /etc/nsswitch.conf نادیده گرفته خواهد شد.

برای پلتفرم‌هایی که روش پیش‌فرضی برای دریافت بایت‌های تصادفی ندارند، این متغیر می‌تواند به نام یک سوکت سیستم‌فایل که دیمن egd یا prngd روی آن در حال گوش دادن است تنظیم شود.
در صورت تنظیم، به mono اعلام می‌کند که برای استفاده از سرویس‌های بومی ورودی/خروجی ناهمگام (native AIO) تلاش کند. در صورت عدم تنظیم، پیاده‌سازی پیش‌فرض select/poll مورد استفاده قرار می‌گیرد. در حال حاضر epoll و kqueue پشتیبانی می‌شوند.
سازوکاری را که Mono برای تعلیق (suspend) ریسه‌ها استفاده خواهد کرد انتخاب می‌کند. می‌تواند مقادیر "preemptive"، "coop" یا "hybrid" را بپذیرد. ممکن است نیاز باشد ریسه‌ها توسط عیب‌یاب، برخی APIهای ریسه‌بندی .NET یا در رایج‌ترین حالت، توسط زباله‌روب SGen در طول یک مرحله حیاتی از زباله‌روبی به حالت تعلیق درآیند. حالت قبضه‌کردنی (preemptive) روشی است که Mono در طول تاریخچه خود و از دوران Boehm به کار گرفته است؛ جایی که زباله‌روب می‌توانست در هر لحظه اجرا شده و طبق نیاز برای اجرای زباله‌روبی، کلیه ریسه‌ها را معلق کند. در مقابل، حالت مشارکتی (cooperative) نیازمند همکاری تمام ریسه‌ها برای توقف در یک نقطه امن (safe point) است. این روش فرایند عیب‌یابی زباله‌روب را آسان‌تر کرده و پایداری زمان اجرا را افزایش می‌دهد، زیرا ریسه‌ها هنگام دسترسی به منابع حساس معلق نمی‌شوند. در مواردی که Mono درون برنامه دیگری جاسازی (embedded) شده است، تعلیق مشارکتی نیازمند رعایت رهنمودهای کدنویسی توسط برنامه میزبان برای تعامل صحیح با زباله‌روب است. تعلیق مشارکتی در Monoی تعبیه‌شده در حال حاضر جنبه آزمایشی دارد. حالت ترکیبی (hybrid) تلفیقی از این دو روش است که سازگاری بهتری را در سناریوهای تعبیه Mono در سایر برنامه‌ها ارائه می‌دهد: ریسه‌هایی که کدهای مدیریت‌شده یا کدهای زمان اجرای Mono را اجرا می‌کنند به‌صورت مشارکتی معلق می‌شوند، در حالی که ریسه‌های مجری کدهای برنامه میزبان به‌صورت قبضه‌کردنی به تعلیق درمی‌آیند. تعلیق ترکیبی در برخی پلتفرم‌های دسکتاپ حالت پیش‌فرض است.

علاوه بر این، حالت‌های coop و hybrid را می‌توان در هنگام کامپایل با استفاده از پرچم‌های --enable-cooperative-suspend یا --enable-hybrid-suspend در زمان فراخوانی configure فعال ساخت. متغیر محیطی MONO_THREADS_SUSPEND بر مقدار پیش‌فرض زمان کامپایل ارجحیت دارد..TP MONO_ENABLE_COOP_SUSPEND این متغیر محیطی منسوخ شده است، اما برای سازگاری با نسخه‌های قبلی حفظ شده است. به جای آن از MONO_THREADS_SUSPEND با مقدار «coop» استفاده کنید. توجه داشته باشید که اگر پرچم‌های پیکربندی (configure) برای فعال‌سازی تعلیق تعاملی (cooperative) یا ترکیبی (hybrid) ارائه شده باشند، این متغیر نادیده گرفته می‌شود.

این متغیر محیطی به شما امکان می‌دهد آرگومان‌های خط فرمان را از طریق محیط به یک فرآیند Mono ارسال کنید. این ویژگی به عنوان مثال برای وادار کردن تمام فرآیندهای Mono به استفاده از LLVM یا SGEN بدون نیاز به تغییر اسکریپت‌های راه‌اندازی مفید است.
برای ارسال گزینه‌های اضافی به عامل دیباگر در زمان اجرا (runtime) استفاده می‌شود، مشابه همان‌گونه که با استفاده از --debugger-agent= ارسال می‌شدند.
نوع ارائه‌دهنده ثبت رویدادها را برای استفاده (جهت System.Diagnostics.EventLog) تعیین می‌کند. مقادیر ممکن عبارتند از:
گزارش‌های رویداد و ورودی‌ها را روی سیستم‌فایل محلی ذخیره می‌کند. دایرکتوری‌ای که گزارش‌های رویداد، منابع رویداد و ورودی‌ها باید در آن ذخیره شوند را می‌توان به عنوان بخشی از مقدار مشخص کرد. اگر مسیر به صراحت مشخص نشده باشد، مقدار پیش‌فرض در یونیکس «/var/lib/mono/eventlog» و در ویندوز «%APPDATA%no\ventlog» خواهد بود.
از API محلی win32 برای نوشتن رویدادها و ثبت گزارش‌های رویداد و منابع رویداد در رجیستری استفاده می‌کند. این ویژگی تنها در ویندوز موجود است. در یونیکس، مجوزهای دایرکتوری برای دایرکتوری‌های مربوط به هر ثبت رویداد و منبع رویداد، روی 777 (همراه با بیت +t) تنظیم می‌شود که به همه اجازه خواندن و نوشتن ورودی‌های گزارش رویداد را می‌دهد، در حالی که حذف ورودی‌ها فقط توسط کاربری (یا کاربرانی) که آن‌ها را ایجاد کرده‌اند امکان‌پذیر است.
بدون هیچ پیامی تمام رویدادها را نادیده گرفته و دور می‌اندازد.

مقدار پیش‌فرض در یونیکس (و نسخه‌های ویندوز قبل از NT) برابر «null» و در ویندوز NT (و بالاتر) برابر «win32» است.

در صورت تنظیم، شامل فهرستی از کدگذاری‌های متنی جداشده با دونقطه (:) است تا هنگام تبدیل متن‌های تولیدشده خارجی (مانند آرگومان‌های خط فرمان یا نام فایل‌ها) به یونیکد امتحان شوند. نام‌های کدگذاری از فهرست ارائه‌شده توسط iconv و همچنین مورد خاص «default_locale» که به کدگذاری پیش‌فرض محلی (locale) فعلی اشاره دارد، برگرفته می‌شوند.
هنگام خواندن رشته‌های متنی تولیدشده خارجی، ابتدا UTF-8 امتحان می‌شود و سپس این فهرست به ترتیب بررسی می‌گردد و اولین تبدیل موفق، جستجو را پایان می‌دهد. هنگام نوشتن متن خارجی (مانند نام فایل‌های جدید یا آرگومان‌های فرآیندهای جدید)، از اولین مورد در این فهرست استفاده می‌شود، یا اگر این متغیر محیطی تنظیم نشده باشد، از UTF-8 استفاده خواهد شد.
مشکل استفاده از MONO_EXTERNAL_ENCODINGS برای پردازش فایل‌ها این است که به یک اشکال منجر می‌شود: با این‌که دستیابی به نام صحیح فایل امکان‌پذیر است، اما لزوماً باز کردن فایل ممکن نخواهد بود. به طور کلی، اگر با کدگذاری در نام فایل‌های خود مشکل دارید، باید از برنامه «convmv» استفاده کنید.
هنگام استفاده از Mono با زباله‌روب SGen، این متغیر چندین پارامتر از این زباله‌روب را کنترل می‌کند. مقدار این متغیر فهرستی از کلمات جداشده با کاما است.
حداکثر اندازه هیپ (heap) را تنظیم می‌کند. اندازه بر حسب بایت مشخص می‌شود و باید توانی از دو باشد. پسوندهای «k»، «m» و «g» می‌توانند به ترتیب برای مشخص کردن کیلو، مگا و گیگابایت استفاده شوند. این محدودیت مجموع nursery، هیپ اصلی (major heap) و هیپ اشیاء بزرگ (large object heap) است. هنگامی که این حد به پایان برسد، برنامه هنگام تلاش برای تخصیص با استثنای OutOfMemoryExceptions مواجه خواهد شد. به دلیل تکه‌تکه‌شدگی داخلی (internal fragmentation)، ممکن است کل حافظه تعیین‌شده در max-heap-size برای پاسخ به یک تخصیص واحد در دسترس نباشد. به طور پیش‌فرض، محدودیت‌های هیپ غیرفعال است و GC سعی می‌کند از تمام حافظه موجود استفاده کند.
اندازه nursery را تعیین می‌کند. اندازه بر حسب بایت مشخص می‌شود و باید توانی از دو باشد. پسوندهای «k»، «m» و «g» را می‌توان به ترتیب برای تعیین کیلو، مگا و گیگابایت به کار برد. بخش nursery نسل اول (از دو نسل) است. یک nursery بزرگ‌تر معمولاً سرعت برنامه را افزایش می‌دهد اما مشخصاً حافظه بیشتری مصرف خواهد کرد. اندازه پیش‌فرض nursery برابر با 4 مگابایت است.
مشخص می‌کند که از کدام جمع‌آورنده اصلی (major collector) استفاده شود. گزینه‌ها عبارتند از «marksweep» برای جمع‌آورنده Mark&Sweep، «marksweep-conc» برای Mark&Sweep هم‌روند، و «marksweep-conc-par» برای Mark&Sweep موازی و هم‌روند. جمع‌آورنده Mark&Sweep هم‌روند، گزینه پیش‌فرض است.
مشخص می‌کند که هدف زباله‌روب چه باید باشد. حالت «throughput» با هدف کاهش زمان صرف‌شده در زباله‌روب و بهبود سرعت برنامه عمل می‌کند؛ حالت «pause» با هدف به حداقل رساندن زمان‌های توقف طراحی شده و آرگومان max-pause را دریافت می‌کند که حداکثر زمان توقف قابل قبول را به میلی‌ثانیه مشخص می‌کند؛ و حالت «balanced» یک حالت بهینه عمومی و چندمنظوره است.
هنگامی که اندازه هیپ از این مقدار فراتر رود، معیار پیش‌فرض شروع جمع‌آوری اصلی نادیده گرفته شده و بین هر دو جمع‌آوری اصلی، تنها به میزان چهار برابر اندازه nursery اجازه رشد به هیپ اصلی داده می‌شود.
آستانه تخلیه (evacuation threshold) را بر حسب درصد تعیین می‌کند. این گزینه فقط در جمع‌آورنده‌های اصلی Mark&Sweep موجود است. مقدار باید یک عدد صحیح در بازه 0 تا 100 باشد. مقدار پیش‌فرض 66 است. اگر فاز جاروب (sweep phase) جمع‌آوری تشخیص دهد که میزان اشغال یک نوع بلوک هیپ خاص کمتر از این درصد است، در جمع‌آوری اصلی بعدی یک جمع‌آوری مبتنی بر کپی برای آن نوع بلوک انجام می‌دهد و در نتیجه میزان اشغال را به نزدیک 100 درصد بازمی‌گرداند. مقدار 0 ویژگی تخلیه را خاموش می‌کند.
(no-)lazy-sweep
جاروب تنبل (lazy sweep) را برای جمع‌آورنده Mark&Sweep فعال یا غیرفعال می‌کند. در صورت فعال بودن، جاروب بلوک‌های مجزای هیپ اصلی به‌صورت تدریجی و هر زمان که نیاز باشد، معمولاً در طول جمع‌آوری‌های nursery انجام می‌شود. جاروب تنبل به طور پیش‌فرض فعال است.
(no-)concurrent-sweep
جاروب هم‌روند (concurrent sweep) را برای جمع‌آورنده Mark&Sweep فعال یا غیرفعال می‌کند. در صورت فعال بودن، پیمایش تمام بلوک‌های اصلی برای تعیین این‌که کدام‌یک می‌توانند آزاد شوند و کدام‌یک باید نگه‌داشته و جاروب شوند، هم‌روند با اجرای برنامه انجام می‌شود. جاروب هم‌روند به طور پیش‌فرض فعال است.
نحوه پویش ریسمان‌های برنامه را مشخص می‌کند. گزینه‌ها عبارتند از «precise» و «conservative». نشانه‌گذاری دقیق (precise) به جمع‌آورنده امکان می‌دهد بداند چه مقادیری روی پشته ارجاع (reference) هستند و چه مقادیری نیستند. نشانه‌گذاری محافظه‌کارانه (conservative) همه مقادیر را به عنوان ارجاعات بالقوه در نظر می‌گیرد و آن‌ها را دست‌نخورده باقی می‌گذارد. نشانه‌گذاری دقیق زباله‌های معلق (floating garbage) را کاهش می‌دهد و می‌تواند جمع‌آوری nursery و نرخ تخصیص را تسریع کند، اما این عیب را دارد که به حافظه اضافی قابل توجهی به ازای هر متد کامپایل‌شده نیاز دارد. متأسفانه انتخاب گزینه مناسب نیازمند آزمایش است.
نسبت ذخیره هدف (target save ratio) را برای جمع‌آورنده اصلی مشخص می‌کند. جمع‌آورنده اجازه می‌دهد مقدار مشخصی از حافظه بر اثر جمع‌آوری‌های جزئی از nursery ارتقا (promote) یابد، پیش از آن‌که یک جمع‌آوری اصلی را آغاز کند. این مقدار بر اساس میزان حافظه‌ای که انتظار دارد آزاد شود تعیین می‌گردد و به عنوان نسبتی از اندازه هیپ پس از یک جمع‌آوری اصلی نشان داده می‌شود. مقادیر معتبر بین 0.1 و 2.0 هستند. مقدار پیش‌فرض 0.5 است. مقادیر کوچک‌تر، اندازه هیپ اصلی را کوچک‌تر نگه می‌دارند اما جمع‌آوری‌های اصلی بیشتری را فراخوانی می‌کنند. به همین ترتیب، مقادیر بزرگ‌تر از حافظه بیشتری استفاده کرده و منجر به تکرار کمتر جمع‌آوری‌های اصلی می‌شوند. این گزینه آزمایشی (EXPERIMENTAL) است، بنابراین ممکن است در نسخه‌های بعدی Mono حذف شود.
سهمیه تخصیص پیش‌فرض را در صورتی که اندازه محاسبه‌شده بسیار کوچک باشد مشخص می‌کند. سهمیه تخصیص، میزان حافظه‌ای است که جمع‌آورنده پیش از آغاز یک جمع‌آوری اصلی اجازه ارتقای آن را می‌دهد. این مقدار نسبتی از اندازه nursery است. مقادیر معتبر بین 1.0 و 10.0 هستند. مقدار پیش‌فرض 4.0 است. مقادیر کوچک‌تر به هیپ‌های کوچک‌تر و جمع‌آوری‌های اصلی مکررتر منجر می‌شوند. به همین ترتیب، مقادیر بزرگ‌تر اجازه می‌دهند هیپ سریع‌تر رشد کند اما هنگام رسیدن به یک اندازه پایدار، حافظه بیشتری مصرف خواهد کرد. این گزینه آزمایشی (EXPERIMENTAL) است، بنابراین ممکن است در نسخه‌های بعدی Mono حذف شود.
مشخص می‌کند که از کدام جمع‌آورنده جزئی (minor collector) استفاده شود. گزینه‌ها عبارتند از «simple» که تمام اشیاء را از nursery مستقیماً به نسل قدیمی ارتقا می‌دهد، «simple-par» که رفتار ارتقای مشابه با «simple» دارد اما از چندین پردازشگر موازی (worker) استفاده می‌کند، و «split» که اجازه می‌دهد اشیاء پیش از ارتقا، مدت بیشتری در nursery باقی بمانند.
نسبتی از حافظه nursery که باید توسط فضای تخصیص (alloc space) استفاده شود را مشخص می‌کند. این گزینه فقط با جمع‌آورنده جزئی split قابل استفاده است. مقادیر معتبر اعداد صحیح بین 1 و 100 هستند. مقدار پیش‌فرض 60 است..TP promotion-age=age سن لازمی را مشخص می‌کند که یک شیء باید پیش از ارتقا به نسل قدیمی (old generation)، در nursery به آن برسد. این گزینه فقط با گردآورنده جزئی تقسیم‌شده (split minor collector) قابل استفاده است. مقادیر معتبر، اعداد صحیح بین 1 و 14 هستند. مقدار پیش‌فرض 2 است.
(no-)cementing
قابلیت cementing را فعال یا غیرفعال می‌کند. این گزینه می‌تواند در برخی محک‌ها (benchmarks) که در آن‌ها از هیپ اصلی (major heap) به اشیاء پین‌شده ارجاع داده می‌شود، زمان‌های گردآوری nursery را به طرز چشمگیری کاهش دهد.
گردآورنده اصلی را از انجام گردآوری‌های اصلی همگام بازمی‌دارد. گردآورنده اصلی ممکن است به دلیل قطعه‌قطعه‌شدگی بیش از حد، تمایل به انجام گردآوری همگام داشته باشد. غیرفعال کردن این گزینه ممکن است در شرایطی که در غیر این صورت مشکلی پیش نمی‌آمد، خطای OutOfMemory ایجاد کند.
هنگام استفاده از Mono با گردآورنده زباله SGen، می‌توان از این متغیر محیطی برای فعال کردن ویژگی‌های مختلف اشکال‌زدایی گردآورنده استفاده کرد. مقدار این متغیر فهرستی از کلمات جداشده با کاما است. از این گزینه‌ها در محیط عملیاتی (production) استفاده نکنید.
سطح اشکال‌زدایی را به عدد مشخص‌شده تنظیم می‌کند.
پس از هر گردآوری اصلی، مصرف حافظه را برای قبل و بعد از گردآوری و همچنین میزان مجاز (allowance) برای گردآورنده جزئی چاپ می‌کند؛ یعنی اینکه پیش از راه‌اندازی گردآوری اصلی بعدی، هیپ چقدر اجازه دارد بر اثر گردآوری‌های جزئی رشد کند.
آمارهایی درباره کلاس‌هایی جمع‌آوری می‌کند که اشیاء آن‌ها در nursery پین شده‌اند و مدخل‌های سراسری remset برای آن‌ها اضافه شده است. این آمارها هنگام خروج چاپ می‌شوند.
این گزینه بررسی سازگاری remset را در موقعیت‌های مختلف انجام می‌دهد و همچنین برخلاف حالت پیش‌فرض که پاک‌سازی هنگام تخصیص بافرها انجام می‌شود، nursery را در زمان گردآوری پاک‌سازی می‌کند (clear-at-gc). بررسی سازگاری تضمین می‌کند که هیچ ارجاعی از major به minor که در مجموعه‌های به‌خاطرسپرده‌شده (remembered sets) نباشد، وجود ندارد.
پیش از هر مکث پایان‌بخش گردآوری اصلی، سازگاری جدول کارت mod-union را بررسی می‌کند. این بررسی فقط برای گردآورنده‌های اصلی هم‌روند (concurrent) قابل اعمال است.
در پایان هر گردآوری اصلی، سازگاری بیت‌های علامت‌گذاری (mark bits) در هیپ اصلی را بررسی می‌کند. بیت‌های علامت‌گذاری سازگار به این معنی است که اگر شیئی علامت‌گذاری شده باشد، تمام اشیایی که به آن‌ها ارجاع دارد نیز باید علامت‌گذاری شده باشند.
پس از گردآوری‌های زباله، بررسی می‌کند که آیا تمام اشاره‌گرهای vtable فاقد برچسب (untagged) شده‌اند یا خیر.
بررسی‌ای انجام می‌دهد تا اطمینان حاصل شود هیچ ارجاعی به یک AppDomain باربرداری‌شده (unloaded) باقی نمانده است.
هنگام ایجاد بافرهای تخصیص محلی ریسه (TLAB)، nursery را به‌صورت افزایشی پاک‌سازی می‌کند. در حالت پیش‌فرض، کل nursery در زمان GC پاک‌سازی می‌شود.
هنگام ایجاد بافرهای تخصیص محلی ریسه (TLAB)، nursery را به‌صورت افزایشی پاک‌سازی می‌کند، اما در زمان GC آن را با بایت `0xff` پر می‌کند، که در صورت کار نکردن درست `clear-at-tlab-creation` باید سریع‌تر منجر به فروپاشی (crash) شود.
این گزینه nursery را در زمان GC پاک‌سازی می‌کند به‌جای اینکه هنگام ایجاد بافر تخصیص محلی ریسه (TLAB) این کار را انجام دهد. پیش‌فرض این است که nursery در زمان ایجاد TLAB پاک‌سازی شود.
گردآوری‌های جزئی انجام نشوند. اگر nursery پر شود، یک گردآوری اصلی به‌جای آن راه‌اندازی خواهد شد، مگر آنکه آن هم غیرفعال شده باشد.
گردآوری‌های اصلی انجام نشوند.
گردآورنده زباله را مجبور می‌کند تا پشته را به‌طور محافظه‌کارانه پویش کند، حتی اگر پویش دقیق در دسترس باشد.
تخصیص‌دهنده مدیریت‌شده (managed allocator) را غیرفعال می‌کند.
تخصیص‌دهنده مدیریت‌شده را فعال می‌کند.
در صورت تنظیم، بررسی معقولیت را قبل و بعد از هر گردآوری روی scan_starts انجام می‌دهد.
در صورت تنظیم، در شروع هر گردآوری جزئی یک پیمایش کامل از اشیاء nursery انجام می‌دهد.
در صورت تنظیم، محتویات nursery را در آغاز هر گردآوری جزئی تخلیه (dump) می‌کند. نیازمند تنظیم بودن verify-nursery-at-minor-gc است.
محتویات هیپ را در فایل مشخص‌شده تخلیه می‌کند. برای مصورسازی این اطلاعات، از ابزار mono-heapviz استفاده کنید.
خروجی اشکال‌زدایی را به فایل مشخص‌شده ارسال می‌کند. برای کارکرد این گزینه، Mono باید با تعریف BINARY_PROTOCOL در sgen-gc.c کامپایل شده باشد. سپس می‌توانید از این دستور برای بررسی خروجی استفاده کنید: 
sgen-grep-binprot 0x1234 0x5678 < file
در صورت تنظیم، اشیاء تخصیص‌یافته در nursery با یک کلمه قناری (canary/نگهبان) پسوندگذاری می‌شوند که در هر گردآوری جزئی بررسی می‌شود. می‌تواند برای شناسایی و اشکال‌زدایی مشکلات خرابی هیپ (heap corruption) استفاده شود. این گزینه استفاده از تخصیص‌دهنده مدیریت‌شده را غیرفعال می‌کند، زیرا تخصیص از کد تماماً AOT با این گزینه ناسازگار است. اگر تضمین شود برنامه از کد AOT استفاده نمی‌کند، می‌توان تخصیص‌دهنده مدیریت‌شده را مجدداً با گزینه managed-allocator فعال کرد.
در صورت فعال بودن، نهایی‌سازها (finalizers) اجرا نخواهند شد. بقیه موارد دست‌نخورده باقی می‌مانند: اشیاء قابل نهایی‌سازی همچنان در صف نهایی‌سازی قرار می‌گیرند و تا زمان زمان‌بندی برای نهایی‌سازی باقی می‌مانند. به محض اینکه دیگر در صف نباشند، به طور معمول گردآوری خواهند شد. اگر فهرستی از نام‌های کلاس جدا شده با کاما ارائه شود، تنها اشیاء مربوط به آن کلاس‌ها نهایی‌سازی نخواهند شد.
برای کمک به اشکال‌زدایی، فرایند نهایی‌سازی را با جزئیات کامل ثبت (log) می‌کند.
پیشوندی را ارائه می‌دهد که زمان اجرا (runtime) از آن برای جستجوی Global Assembly Cacheها استفاده می‌کند. دایرکتوری‌ها با جداکننده مسیر پلتفرم (دونقطه در یونیکس) از یکدیگر جدا می‌شوند. MONO_GAC_PREFIX باید به دایرکتوری سطح بالای یک نصب پیشونددار یا به دایرکتوری ارائه‌شده در دستور gacutil /gacdir اشاره کند. مثال: /home/username/.mono:/usr/local/mono/
(منسوخ‌شده) پشتیبانی از بازنویسی برخی نام‌های فایل را برای کمک به برنامه‌های ضعیف نوشته‌شده که مسیرهای Windows را هاردکد (hard-code) کرده‌اند فعال می‌کرد. این قابلیت از Mono 6.0 به بعد دیگر کار نمی‌کند.
هنگامی که Mono از backend تولید کد LLVM استفاده می‌کند، می‌توانید از این متغیر محیطی برای ارسال گزینه‌های تولید کد به کامپایلر LLVM استفاده کنید.
اگر روی "disabled" تنظیم شود، System.IO.FileSystemWatcher از پیاده‌سازی دیده‌بان فایلی استفاده خواهد کرد که بدون هیچ پیامی تمام درخواست‌های پایش را نادیده می‌گیرد. اگر روی هر مقدار دیگری تنظیم شود، System.IO.FileSystemWatcher از پیاده‌سازی مدیریت‌شده پیش‌فرض (کند) استفاده خواهد کرد. در صورت عدم تنظیم، mono سعی می‌کند از inotify، FAM، Gamin، kevent در سیستم‌های یونیکس و فراخوانی‌های بومی API در Windows استفاده کند و در صورت بروز خطا به پیاده‌سازی مدیریت‌شده بازگردد.
Mono از یک مدل افزونه (plugin) برای پیاده‌سازی System.Messaging پشتیبانی می‌کند که امکان پشتیبانی از پیاده‌سازی‌های پیام‌رسانی گوناگون (مانند AMQP و ActiveMQ) را فراهم می‌آورد. برای تعیین اینکه کدام پیاده‌سازی پیام‌رسانی باید استفاده شود، این متغیر محیطی باید روی نام کامل کلاس ارائه‌دهنده (provider) تنظیم شود. به عنوان مثال برای استفاده از پیاده‌سازی AMQP مبتنی بر RabbitMQ، متغیر باید روی مقدار زیر تنظیم شود: 
Mono.Messaging.RabbitMQ.RabbitMQMessagingProvider,Mono.Messaging.RabbitMQ.TP
MONO_NO_SMP
در صورت تنظیم، باعث می‌شود فرآیند mono به یک پردازنده محدود شود. این گزینه ممکن است هنگام اشکال‌زدایی یا دور زدن شرایط رقابتی (race conditions) مفید باشد.
غیرفعال کردن خطی‌سازی دسترسی‌های محلی ریسه (thread local). اگر در ابتدای اجرای mono با خطای segfault مواجه شدید، تنظیم این متغیر را امتحان کنید.
مسیر جستجویی را برای زمان اجرا فراهم می‌کند تا در آن به دنبال فایل‌های کتابخانه بگردد. این ابزار برای اشکال‌زدایی برنامه‌ها بسیار مناسب است، اما نباید در برنامه‌های مستقر شده استفاده شود زیرا بارگذار اسمبلی (assembly loader) را به شکل نامحسوسی دچار مشکل می‌کند.
دایرکتوری‌ها با جداکننده مسیر پلتفرم (دونقطه در یونیکس) از هم جدا می‌شوند. مثال:
/home/username/lib:/usr/local/mono/lib
مسیرهای نسبی بر اساس دایرکتوری جاری در زمان اجرا حل‌وفصل می‌شوند.
راهکارهای جایگزین برای MONO_PATH عبارتند از: نصب کتابخانه‌ها در Global Assembly Cache (به gacutil(1) مراجعه کنید) یا قرار دادن کتابخانه‌های وابسته در کنار فایل اجرایی اصلی.
برای توضیحات کامل درباره شیوه‌های توصیه‌شده استقرار برنامه، به نشانی زیر مراجعه کنید:
http://www.mono-project.com/docs/getting-started/application-deployment
در صورت تنظیم، دایرکتوری‌ای است که وضعیت دستگیره (handle) فایل‌های «.wapi» در آن ذخیره می‌شود. این دایرکتوری محلی است که لایه شبیه‌سازی Windows I/O داده‌های وضعیت مشترک خود (فایل‌ها، رویدادها، موتکس‌ها و پایپ‌ها) را در آن نگهداری می‌کند. به‌طور پیش‌فرض، Mono دایرکتوری «.wapi» را در دایرکتوری خانگی کاربر ذخیره خواهد کرد.
از مقدار متنی این متغیر به عنوان جایگزین نام میزبان (hostname) هنگام ایجاد نام فایل‌ها در دایرکتوری «.wapi» استفاده می‌کند. این گزینه زمانی کمک می‌کند که احتمال دارد نام میزبان رایانه شما در حین اجرای برنامه mono تغییر کند، یا زمانی که یک دایرکتوری .wapi بین چندین رایانه مختلف به اشتراک گذاشته شده باشد.
‏Mono معمولاً از نام میزبان برای ایجاد فایل‌هایی استفاده می‌کند که جهت اشتراک وضعیت بین چندین فرآیند Mono به کار می‌روند. این کار برای پشتیبانی از دایرکتوری‌های خانگی به اشتراک‌گذاشته‌شده در شبکه انجام می‌گیرد.
در صورت تنظیم، بررسی‌های بیشتری در حین عملیات ورودی/خروجی (IO) انجام می‌گیرد. در حال حاضر، این فقط شامل قفل‌های مشورتی (advisory locks) در هنگام نوشتن فایل است.
این متغیر محیطی تعیین می‌کند که Mono از کدام ارائه‌دهنده TLS/SSL استفاده کند. گزینه‌ها معمولاً توسط سیستم‌عاملی که Mono روی آن کامپایل شده و گزینه‌های پیکربندی استفاده‌شده برای آن مشخص می‌شوند.
از پشته پیش‌فرض TLS که زمان اجرای Mono با آن پیکربندی شده است استفاده می‌کند. معمولاً این پشته برای استفاده از پشته SSL اپل روی پلتفرم‌های Apple، و Boring SSL روی سایر پلتفرم‌ها پیکربندی می‌شود.
استفاده از پشته SSL اپل را اجبار می‌کند؛ تنها روی پلتفرم‌های Apple کارایی دارد.
استفاده از پشته BoringSSL را اجبار می‌کند. برای اطلاعات بیشتر درباره این پشته به نشانی
https://opensource.google.com/projects/boringssl
مراجعه کنید.
این پشته قدیمی Mono است که تنها از SSL و TLS تا نگارش 1.0 پشتیبانی می‌کند. این پشته منسوخ شده است و در آینده حذف خواهد شد.
مدت زمان (به ثانیه) که حافظه پنهان (cache) نشست SSL/TLS ورودی خود را نگه می‌دارد تا از مذاکره مجدد میان کارخواه و کارگزار جلوگیری شود. فرآیند مذاکره مصرف پردازنده بسیار بالایی دارد، بنابراین یک مقدار سفارشی برای برنامه‌ای خاص ممکن است در سیستم‌های نهفته کوچک مفید باشد.
مقدار پیش‌فرض 180 ثانیه است.
حداقل تعداد ریسه‌ها در استخر سراسری ریسه‌ها (threadpool) برابر خواهد بود با MONO_THREADS_PER_CPU * تعداد پردازنده‌ها. مقدار پیش‌فرض این متغیر 1 است.
آستانه را برای XmlSerializer کنترل می‌کند تا به جای استفاده از مفسر مبتنی بر Reflection، یک سریال‌ساز سفارشی برای یک کلاس مشخص تولید کند. مقادیر مجاز عبارتند از `no` برای غیرفعال کردن سریال‌ساز سفارشی، یا یک عدد برای مشخص کردن زمانی که XmlSerializer باید سریال‌سازی را آغاز کند. مقدار پیش‌فرض 50 است، به این معنی که سریال‌ساز سفارشی در پنجاهمین بار استفاده ساخته خواهد شد.
حالت ابطال (revocation mode) مورد استفاده هنگام اعتبارسنجی زنجیره گواهی X509 (مانند https، ftps، smtps و غیره) را تعیین می‌کند. مقدار پیش‌فرض 'nocheck' است که هیچ بررسی ابطالی انجام نمی‌دهد. سایر مقادیر ممکن عبارتند از 'offline' که بررسی CRL را انجام می‌دهد (هنوز پیاده‌سازی نشده است) و 'online' که از OCSP و CRL برای بررسی وضعیت ابطال استفاده می‌کند (هنوز پیاده‌سازی نشده است).
(همچنین no_proxy) اگر هم HTTP_PROXY و هم NO_PROXY تنظیم شده باشند، با NO_PROXY به عنوان فهرستی از دامنه‌های استثنا (bypass) جدا شده با کاما رفتار می‌شود که ترافیک آن‌ها از پروکسی عبور داده نخواهد شد. دامنه‌ها در NO_PROXY می‌توانند شامل نویسه‌های عام (wildcard) مانند "*.mono-project.com" یا "build????.local" باشند. روی سیستم‌عامل‌های Windows، Mac OS، iOS یا Android پشتیبانی نمی‌شود..SH "متغیرهای محیطی برای اشکال‌زدایی (ENVIRONMENT VARIABLES FOR DEBUGGING)"
در صورت تنظیم روی هر مقداری، فایل‌های منبع موقت تولیدشده توسط کلاس‌های پشتیبانی ASP.NET حذف نخواهند شد. آن‌ها در دایرکتوری موقت کاربر نگهداری می‌شوند.
در صورت تنظیم، برخی از قابلیت‌های زمان‌اجرا (runtime) را که برای اشکال‌زدایی مفید هستند فعال می‌کند. این متغیر باید شامل فهرستی از گزینه‌های اشکال‌زدایی باشد که با کاما از هم جدا شده‌اند. در حال حاضر، گزینه‌های زیر پشتیبانی می‌شوند:
ترازسازی ساختارهای کوچک (structs) به ۴/۸ بایت را فعال می‌کند.
هنگامی که این گزینه روی ARM تنظیم شود، به جای دستورات اولیه سریعِ پیش‌فرض برای ذخیره‌سازی محلی رشته (thread local storage)، از یک ذخیره‌ساز محلی رشته جایگزین (fallback) استفاده خواهد شد.
اگر این متغیر تنظیم شود، هنگامی که Mono VM با یک مشکل اعتبارسنجی مواجه گردد، به جای پرتاب یک استثنا (exception)، وارد اشکال‌زدا می‌شود. این گزینه هنگام اشکال‌زدایی مشکلات اعتبارسنج (verifier) کاربرد دارد.
casts
از این گزینه می‌توان برای دریافت اطلاعات دقیق‌تر از استثناهای InvalidCast استفاده کرد؛ این گزینه اطلاعاتی درباره انواع (types) دخیل ارائه می‌دهد.
این گزینه باعث می‌شود زمان‌اجرا عدم تطابق در قرارداد فراخوانی (calling convention) را هنگام استفاده از pinvoke (یعنی ترکیب cdecl/stdcall) بررسی کند. این گزینه فقط در Windows کار می‌کند. در صورت تشخیص عدم تطابق، یک ExecutionEngineException پرتاب می‌شود.
اطلاعات مربوط به خطاهای صفحه (pagefaults) را جمع‌آوری می‌کند. این گزینه به‌صورت داخلی برای ردیابی تعداد خطاهای صفحه‌ی ایجادشده جهت بارگذاری فراداده (metadata) استفاده می‌شود. برای نمایش این اطلاعات باید از این گزینه به همراه گزینه خط فرمان "--stats" استفاده کنید.
هنگامی که این گزینه تنظیم شود، زمان‌اجرا به جای نابود کردن مخزن حافظه دامنه (domain memory pool)، آن را نامعتبر می‌سازد.
بهینه‌سازی کامپایلر را که در آن اشاره‌گر فریم (frame pointer) از پشته حذف می‌شود، غیرفعال می‌کند. این بهینه‌سازی می‌تواند تعامل نامطلوبی با اشکال‌زداها داشته باشد.
این یک بهینه‌سازی برای برنامه‌های دارای چند AppDomain (عمدتاً برنامه‌های ASP.NET) است. به دلیل محدودیت‌های داخلی Mono، به‌طور پیش‌فرض Mono در برنامه‌های چند AppDomain از تخصیص‌های نوع‌دار (typed allocations) استفاده نمی‌کند، چرا که ممکن است هنگام تخلیه یک دامنه باعث نشت حافظه شوند.
اگرچه این یک پیش‌فرض مناسب است، برای برنامه‌هایی که استفاده سنگینی از بیش از یک AppDomain دارند (برای مثال، برنامه‌های ASP.NET)، صرف‌نظر کردن از نشتی‌های جزئی در ازای افزایش کارایی ارزش دارد (علاوه بر این، از آنجا که برنامه‌های ASP.NET احتمالاً دامنه‌های برنامه را در سیستم‌های عملیاتی تخلیه نمی‌کنند، استفاده از این ویژگی به‌صرفه است).
به زمان‌اجرا دستور می‌دهد که به جای ساخت یک بسته‌بند (wrapper) فراخوانی، تلاش کند از یک بسته‌بند عمومی runtime-invoke استفاده کند.
باعث می‌شود JIT هنگام ارجاع‌زدایی متغیرها، به جای تکیه بر سیستم‌عامل برای ارسال یک SIGSEGV یا شکل دیگری از رویداد تله (trap) در زمان دسترسی به یک مکان نامعتبر حافظه، یک بررسی صریح NULL تولید کند.
gdb
معادل تنظیم متغیر MONO_XDEBUG است؛ این گزینه هم‌زمان با کامپایل JIT کد، نمادها را در یک کتابخانه مشترک منتشر می‌کند تا بتوان آن‌ها را جهت بررسی در GDB بارگذاری کرد.
به‌طور خودکار در جاهایی که پشته IL خالی است، نقاط توالی (sequence points) تولید می‌کند. این‌ها مکان‌هایی هستند که اشکال‌زدا می‌تواند یک نقطه توقف (breakpoint) در آن‌ها تنظیم کند.
باعث می‌شود که بخش پشتیبانی (backend) نرم‌افزار LLVM روی ارجاع‌زدایی متغیرها از بررسی‌های صریح NULL استفاده کند، به جای تکیه بر پشتیبانی سیستم‌عامل از سیگنال‌ها یا تله‌ها هنگام دسترسی به یک مکان نامعتبر حافظه. این گزینه بدون قید و شرط توسط explicit-null-checks فعال می‌شود.
مگر اینکه از این گزینه استفاده شود، زمان‌اجرا داده‌های نقاط توالی را تولید می‌کند که آفست‌های بومی (native) را به آفست‌های IL نگاشت می‌کند. داده‌های نقاط توالی برای نمایش آفست IL در ردگیری پشته (stacktrace) استفاده می‌شوند. ردگیری‌های پشته حاوی آفست‌های IL را می‌توان با ابزار mono-symbolicate نمادگذاری کرد.
سیگنال وقفه (Control-C) را دریافت کرده و در صورت فشرده شدن آن، یک ردگیری پشته (stack trace) نمایش می‌دهد. برای آگاهی از اینکه برنامه در یک نقطه معین در کجا در حال اجراست مفید است. این گزینه فقط ردگیری پشته یک رشته (thread) منفرد را نمایش می‌دهد.
به زمان‌اجرا دستور می‌دهد تا پشته را در آغاز یک متد با مقادیر مشخصی (0x2a در x86-64) مقداردهی اولیه کند تا به اشکال‌زدایی موتور JIT کمک نماید.
این گزینه ترامپولین‌های نماینده (delegate trampolines) را که دیگر به آن‌ها ارجاعی وجود ندارد آزاد نمی‌کند (نشت می‌دهد) تا اطلاعات بیشتری درباره استفاده نادرست از delegate به کاربر ارائه دهد. اساساً ممکن است یک نمونه delegate ایجاد شود، به کد مدیریت‌نشده (unmanaged) ارسال گردد و هیچ ارجاعی در کد مدیریت‌شده (managed) باقی نماند، که منجر به بازیافت حافظه (garbage collect) آن خواهد شد. با این گزینه، رهگیری منبع مشکلات امکان‌پذیر است.
این گزینه ردگیری پشته (backtrace) مربوط به GDB را که پس از وقوع یک SIGSEGV یا SIGABRT در کد مدیریت‌نشده توسط زمان‌اجرا صادر می‌شود، غیرفعال می‌کند.
هنگامی که این گزینه تنظیم شود، زمان‌اجرا می‌تواند کد تولیدشده را بین انواع جنریک (generic types) به اشتراک بگذارد که به شکلی مؤثر حجم کد تولیدشده را کاهش می‌دهد.
این گزینه باعث می‌شود که هنگام بازپیچی پشته (stack unwinding) پس از یک استثنا، در صورت رسیدن به یک فریم پشته بومی (native)، اجرای mono با پیامی توصیفی متوقف (abort) شود. این حالت زمانی رخ می‌دهد که یک نماینده مدیریت‌شده به کد بومی ارسال شود و آن نماینده مدیریت‌شده استثنایی پرتاب کند. Mono به‌طور معمول تلاش می‌کند پشته را تا نخستین مدیریت‌کننده استثنای (مدیریت‌شده) بازپیچی کند و در این فرایند هر فریم پشته بومی را نادیده می‌گیرد. این امر منجر به رفتار تعریف‌نشده (زیرا mono نحوه پردازش فریم‌های بومی را نمی‌داند)، نشتی و احتمالاً خرابی (crash) نیز می‌شود.
تضمین می‌کند که در هر بار کامپایل کد مدیریت‌شده، صرف‌نظر از اندازه مقادیرِ استفاده‌شده، دستورالعمل‌ها و ثبات‌های یکسانی استفاده شوند.
این گزینه امکان استفاده از تک‌گام‌ها (single-steps) و نقاط توقف را در سخت‌افزارهایی که نمی‌توان در آن‌ها با سیگنال‌ها این کار را انجام داد، فراهم می‌کند.
این گزینه در هنگام بروز یک خرابی بومی (SIGSEGV، SIGILL، ...) برنامه را معلق می‌کند. این گزینه برای اشکال‌زدایی خرابی‌هایی که زیر gdb رخ نمی‌دهند مفید است، زیرا یک فرایند زنده حاوی اطلاعات بیشتری نسبت به یک فایل core است.
مشابه suspend-on-native-crash است.
این گزینه در صورت بروز یک استثنا، برنامه را معلق می‌کند.
این گزینه در صورت بروز یک استثنای مدیریت‌نشده، برنامه را معلق می‌کند.
از DIR برای نگهداری دامپ‌های رشته که توسط SIGQUIT ایجاد می‌شوند استفاده می‌کند.
مدل حافظه CLR را در پلتفرم‌هایی با مدل‌های حافظه ضعیف اعمال نمی‌کند. این کار می‌تواند در برخی موارد نادر، در محیط‌های چندرشته‌ای خرابی‌های تصادفی ایجاد کند. از این گزینه می‌توان برای افزایش کارایی در برنامه‌های تک‌رشته‌ای استفاده کرد.
خروجی gdb را هنگام خرابی‌های بومی پرجزئیات‌تر (verbose) می‌کند.
سطح ثبت وقایع؛ مقادیر ممکن عبارتند از `error'، `critical'، `warning'، `message'، `info' و `debug'. برای جزئیات بیشتر بخش اشکال‌زدایی (DEBUGGING) را ببینید.
دامنه زمان‌اجرای Mono را که ثبت وقایع روی آن اعمال خواهد شد، کنترل می‌کند. در صورت تنظیم، ماسک گزارش به مقدار تعیین‌شده تغییر می‌یابد. مقادیر ممکن عبارتند از "asm" (بارگذار اسمبلی)، "type"، "dll" (بارگذار کتابخانه بومی)، "gc" (زباله‌روب)، "cfg" (بارگذار فایل پیکربندی)، "aot" (پیش‌کامپایلر)، "security" (مانند پشتیبانی از Moonlight CoreCLR) و "all". مقدار پیش‌فرض "all" است. تغییر مقدار ماسک به شما اجازه می‌دهد تنها پیام‌های مربوط به یک مؤلفه خاص را نمایش دهید. می‌توانید با جدا کردن آن‌ها با کاما، از چند ماسک استفاده کنید. برای مثال، جهت دیدن پیام‌های فایل پیکربندی و پیام‌های بارگذار اسمبلی، ماسک خود را روی "asm,cfg" تنظیم کنید..TP
MONO_LOG_DEST
محل نوشتن پیام‌های گزارش ردگیری (trace log) را کنترل می‌کند. اگر تنظیم نشده باشد، پیام‌ها به stdout ارسال می‌شوند.
در صورت تنظیم، این رشته یا مسیری به یک فایل را مشخص می‌کند که پیام‌ها به آن افزوده می‌شوند، یا رشته‌ی "syslog" است که در این صورت پیام‌ها در گزارش سیستم (system log) نوشته خواهند شد.
در Windows، این قابلیت با نوشتن در فایلی به نام "mono.log" شبیه‌سازی می‌شود.
MONO_LOG_HEADER
کنترل می‌کند که آیا پیام‌های گزارش ردگیری که به syslog هدایت نشده‌اند، شناسه‌ (id)، برچسب زمانی (timestamp) و pid را به عنوان پیشوند پیام داشته باشند یا خیر. برای فعال‌سازی این سرآیند، کافی است این متغیر محیطی مقداری غیرتهی (non-null) داشته باشد.
برای ردگیری فراخوانی‌های متد در زمان اجرا به کار می‌رود. قالب گزینه‌های ردگیری که با کاما از هم جدا می‌شوند به این صورت است:
	[-]M:method name
	[-]N:namespace
	[-]T:class name
	[-]all
	[-]program
	disabled		Trace output off upon start.
می‌توانید با ارسال سیگنال SIGUSR2 به برنامه، خروجی ردگیری را فعال یا غیرفعال کنید.
در صورت تنظیم، کلاس System.Diagnostics.DefaultTraceListener را فعال می‌کند که خروجی کلاس‌های Trace و Debug از System.Diagnostics را چاپ خواهد کرد. این متغیر می‌تواند روی یک نام فایل، یا برای نمایش خروجی به ترتیب در خروجی استاندارد یا خطای استاندارد، روی Console.Out یا Console.Error تنظیم شود. اگر روی Console.Out یا Console.Error تنظیم شده باشد، می‌توانید یک پیشوند اختیاری اضافه کنید که هنگام نوشتن پیام‌ها به این صورت استفاده می‌شود: Console.Error:MyProgramName. برای اطلاعات بیشتر مستندات System.Diagnostics.DefaultTraceListener را ببینید.
با هدایت تمام پیام‌های گزارش از موتور WCF به "stdout" یا "stderr" یا هر فایلی که به این متغیر محیطی داده شود، قابلیت‌های عیب‌یابی WCF را تسهیل می‌کند. قالب گزارش مشابه خروجی معمول عیب‌یابی است.
هنگام مواجهه با خطای X11، یک استثنا صادر می‌کند؛ به صورت پیش‌فرض پیامی نمایش داده می‌شود اما اجرای برنامه ادامه می‌یابد.
مقدار این متغیر را برابر 1 قرار دهید تا از حذف فایل‌های موقتی که برای سریال‌سازی سریع ایجاد شده‌اند توسط سریال‌ساز جلوگیری شود؛ این کار ممکن است هنگام اشکال‌زدایی مفید باشد.
در پیاده‌سازی System.Windows.Forms هنگام اجرا با backend مربوط به X11 استفاده می‌شود. این متغیر برای اشکال‌زدایی مشکلات در Windows.Forms به کار می‌رود، زیرا تمامی دستورهای ارسال‌شده به سرور X11 را مجبور می‌کند تا به صورت همگام انجام شوند. حالت عملیاتی پیش‌فرض ناهمگام است که ریشه‌یابی برخی مشکلات را دشوار می‌کند.
هنگامی که متغیر محیطی MONO_XDEBUG تنظیم شود، اطلاعات اشکال‌زدایی برای کدهای کامپایل‌شده توسط JIT در یک کتابخانه مشترک (shared library) درج می‌شود که در gdb قابل بارگذاری است. این قابلیت، به عنوان مثال، امکان مشاهده‌ی نام فریم‌های مدیریت‌شده (managed frame names) را در backtraceهای gdb فراهم می‌کند.
حداکثر میزان جزئیات خروجی JIT را برای متد مشخص‌شده فعال می‌کند. این قابلیت برای عیب‌یابی مشکلات کامپایل نادرست یک متد خاص بسیار مفید است. این مقدار می‌تواند فهرستی از نام‌های متد باشد که با نقطه‌ویرگول (;) از هم جدا شده‌اند. اگر نام ساده باشد، برای هر متدی با آن نام اعمال می‌شود؛ در غیر این صورت می‌توانید از توصیف متد mono استفاده کنید (بخش METHOD DESCRIPTIONS را ببینید).
ارسال نمایش میانی (intermediate representation) مربوط به JIT را برای یک متد مشخص به ابزار IdealGraphVisualizer فعال می‌کند.
در صورت تنظیم، باعث می‌شود JIT اطلاعات مربوط به ویژگی‌های شناسایی‌شده CPU (مانند SSE، CMOV، FCMOV و غیره) را در stdout چاپ کند.
در صورت تنظیم، JIT هیچ‌گونه شناسایی قابلیت‌های سخت‌افزاری را انجام نخواهد داد. این گزینه ممکن است برای تعیین دقیق علت مشکلات JIT مفید باشد. این حالت هنگام ساخت Mono به عنوان یک کامپایلر چندسکویی (cross compiler) AOT پیش‌فرض است تا کد تولیدشده روی اکثر سخت‌افزارها قابل اجرا باشد..SH VALGRIND اگر می‌خواهید از Valgrind استفاده کنید، فایل “mono.supp” را مفید خواهید یافت؛ این فایل شامل نادیده‌گیری‌ها برای GC است که هشدارهای نادرست تولید می‌کنند. از آن به این شکل استفاده کنید: 
valgrind --suppressions=mono.supp mono ...

در برخی پلتفرم‌ها، Mono می‌تواند مجموعه‌ای از کاوشگرهای DTrace (که با عنوان کاوشگرهای USDT یا تعریف‌شده به‌صورت ایستا در فضای کاربری نیز شناخته می‌شوند) را ارائه دهد.

آن‌ها در فایل “mono.d” تعریف شده‌اند.
آغاز و پایان مقداردهی اولیه محیط زمان اجرا (runtime).
آغاز و پایان کامپایل متد. آرگومان‌های کاوشگر عبارتند از نام کلاس، نام متد و امضا، و در مورد method-compile-end موفقیت یا شکست در کامپایل.
آغاز و پایان زباله‌روبی (Garbage Collection).
برای بررسی در دسترس بودن کاوشگرها، اجرا کنید:
dtrace -P mono'$target' -l -c mono

پیاده‌سازی Ping در Mono برای تشخیص دسترسی‌پذیری شبکه می‌تواند بدون نیاز به دستور ping سیستم، خودش بسته‌های ICMP را ایجاد کند. اگر می‌خواهید این قابلیت را در لینوکس برای کاربران غیر ریشه (non-root) فعال کنید، باید به باینری Mono مجوزهای ویژه‌ای بدهید.

به‌عنوان کاربر ریشه (root)، این دستور را اجرا کنید:

# setcap cap_net_raw=+ep /usr/bin/mono

در یونیکس اسمبلی‌ها از دایرکتوری lib محل نصب بارگذاری می‌شوند. اگر `prefix` را روی /usr تنظیم کنید، اسمبلی‌ها در /usr/lib قرار خواهند گرفت. در ویندوز، اسمبلی‌ها از همان دایرکتوری‌ای که mono و mint قرار دارند بارگذاری می‌شوند.

~/.mono/aot-cache
دایرکتوری‌ای که در آن اسمبلی‌های ایجادشده بر حسب تقاضای کامپایلر زمان پیش از اجرا (AOT) قرار می‌گیرند.
/etc/mono/config, ~/.mono/config
فایل پیکربندی محیط زمان اجرای Mono. برای اطلاعات بیشتر صفحه راهنمای mono-config(5) را ببینید.
~/.config/.mono/certs, /usr/share/.mono/certs
شامل مخازن گواهی‌های Mono برای کاربران / ماشین است. برای اطلاعات بیشتر درباره مدیریت مخازن گواهی صفحه راهنمای certmgr(1) و برای اطلاعات درباره نحوه وارد کردن گواهی‌های ریشه موزیلا به مخزن گواهی‌های Mono صفحه راهنمای mozroots(1) را ببینید.
~/.mono/assemblies/ASSEMBLY/ASSEMBLY.config
فایل‌های موجود در این دایرکتوری به کاربر اجازه می‌دهند تا پیکربندی را برای یک اسمبلی سیستمی مشخص سفارشی‌سازی کند؛ قالب آن همان قالبی است که در صفحه mono-config(5) توضیح داده شده است.
~/.config/.mono/keypairs, /usr/share/.mono/keypairs
شامل جفت‌کلیدهای رمزنگاری Mono برای کاربران / ماشین است. آن‌ها می‌توانند با استفاده از یک شیء CspParameters همراه با کلاس‌های DSACryptoServiceProvider و RSACryptoServiceProvider در دسترس قرار گیرند.
~/.config/.isolatedstorage, ~/.local/share/.isolatedstorage, /usr/share/.isolatedstorage
شامل فضای ذخیره‌سازی ایزوله (isolated storage) Mono برای کاربران غیرگردشی (non-roaming)، کاربران گردشی (roaming) و ماشین محلی است. فضای ذخیره‌سازی ایزوله با استفاده از کلاس‌های فضای نام System.IO.IsolatedStorage قابل دسترسی است.
<assembly>.config
اطلاعات پیکربندی برای تک‌تک اسمبلی‌ها توسط محیط زمان اجرا از فایل‌های هم‌جوار با فایل‌های .config بارگذاری می‌شود؛ برای اطلاعات بیشتر http://www.mono-project.com/Config را ببینید.
برنامه‌های کاربردی ASP.NET از طریق این فایل‌ها پیکربندی می‌شوند؛ این پیکربندی بر پایه هر دایرکتوری انجام می‌گیرد. برای اطلاعات بیشتر در این رابطه به صفحه http://www.mono-project.com/Config_system.web مراجعه کنید..SH "فهرست‌های پستی (MAILING LISTS)" فهرست‌های پستی در این نشانی فهرست شده‌اند: http://www.mono-project.com/community/help/mailing-lists

http://www.mono-project.com

certmgr(1), cert-sync(1), csharp(1), gacutil(1), mcs(1), monodis(1), mono-config(5), mono-profilers(1), mprof-report(1), pdb2mdb(1), xsp(1), mod_mono(8)

برای اطلاعات بیشتر درباره AOT: http://www.mono-project.com/docs/advanced/aot

برای مستندات مرتبط با ASP.NET، صفحه راهنمای xsp(1) را ببینید