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

[Jonathan Pryor]

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:

	http://msdn.microsoft.com/en-us/library/system.environment.userinteractive(v=vs.110).aspx

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:

	https://github.com/mono/mono/blob/master/mcs/class/corlib/System/Environment.cs#L297

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