On Mar 14, 2014, at 8:42 AM, MarLOne <infoseeker...@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
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
