[Mono-dev] Inconsistent value in System.Diagnostics.DefaultTraceListener.AssertUiEnabled

Jonathan Pryor jonpryor at vt.edu
Thu Mar 20 20:15:39 UTC 2014

On Mar 14, 2014, at 8:42 AM, MarLOne <InfoSeeker002 at gmail.com> wrote:
> The function System.Diagnostics.Debug.Assert(bool, string) is not at fault as I have disassembled the Mono code. The fault lies in the property value of *System.Diagnostics.DefaultTraceListener.AssertUiEnabled* which is default to *false* in *Mono* while in *CLR's runtime code* it is default to *true*.

This behavior is unlikely to change until:

1. We determine a way to reliably (portably!) determine if there is an "interactive" user so that the GUI is not shown in Server context. .NET has the Environment.UserInteractive property for this purpose:


Unfortunately, it isn't implemented in Mono (it just returns `false`), never has been implemented, and I have no idea _how_ to implement it off Windows:


Until this is fixed, DefaultTraceListener.AssertUiEnabled CANNOT be True. (Not unless you want some random headless Server to be trying to connect to the GUI, halting all operations...)

2. It relies on loading System.Windows.Forms.dll via Reflection at runtime. What should happen when that assembly isn't available, as will be the case in Xamarin.Android, Xamarin.iOS, Xamarin.Mac, and various embedded platforms that include Mono's BCL (MonoGame, Unity3D, etc.)?

What _will_ happen is the UI won't be displayed and (in the MOBILE profile) the error message will be logged to stdout.

YOU know in what environments your app will run; the core libraries do not. Therefore, YOU can alter default behaviors as you see fit, e.g. by explicitly setting DefaultTraceeListener.AssertUiEnabled=true (either in code or in a .exe.config file), or by adding a new TraceListener which aborts the process on failure.

 - Jon

More information about the Mono-devel-list mailing list