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

["Andrés G. Aragoneses"]

Have you opened bugs on their bug tracking systems? If yes, this
discussion should be placed there. If not, you should open them, and
provide patches (maybe they didn't do it on purpose, and would be very
grateful of someone trying to remove workarounds/hacks from their code).

Regards,

	Andrés

Lucas Meijer wrote:
> 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