[Mono-dev] Arguing for reconsideration of WONTFIX status of 425512

[Lucas Meijer]

Hey,

Our team has been busy porting some unit testing related frameworks to mono.
porting is probably not the right word, it's mostly creating repro cases 
of mono bugs,
reporting them, and waiting for them to be fixed. (Which happens fast by 
the way. Thanks!)

So far we're looking at NInject, Moq and xUnit.

There are / have been bugs in mono that prevent all of these projects 
from running.
Most of them are valid mono bugs, nothing special here.

In addition to real mono bugs, there's also the fact that many of these 
frameworks, use this
commonly used "trick":

FieldInfo remoteStackTraceString = 
typeof(Exception).GetField("_remoteStackTraceString", 
BindingFlags.Instance | BindingFlags.NonPublic);

This doesn't work on mono, since in mono the private field storing the 
stacktrace is called "remote_stack_trace".

This issue has been reported before as issue 425512 ( 
https://bugzilla.novell.com/show_bug.cgi?id=425512 )

One could argue, and the reason for the wontfix status of the issue does 
so,  that these folks rely on undocumented internals.
They shouldn't do it, and Mono shouldn't rename it's own private field 
to match that of the CLR.

However, in the real world(tm),  this prevents many projects from 
running on Mono unmodified.

I would like to argue that in this specific case, where the (percieved 
by me, maybe incorrectly) amount of work for mono to change it's private 
fieldname to
match that of the CLR, is a reasonable cost for enabling this quite 
frequently found in the wild trick of grabbing the internal stack trace 
of an exception.

Maybe I'm underestimating the amount of work to rename the mono 
fieldname to match the clr one. If that's the case, please consider this 
message
as another datapoint of three useful .net frameworks unable to run on 
mono unmodified.

Here's a bit more info on the trick:

Here is a bit more background on the trick:
http://www.dotnetjunkies.com/WebLog/chris.taylor/archive/2004/03/03/8353.aspx

Bye, Lucas