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

[Stifu]

I have to agree.

Reverse-engineering complicated algorithms for the sake of matching MS .NET
perfectly is one thing, and may not be worth the time and efforts, but
simply changing a string to improve compatibility is an easy win.

Many things in the past of Mono have been done to improve compatibility with
existing .NET apps and get Windows developers interested (such as
Windows.Forms support, for example). Simply put, it doesn't make much sense
to me to try that hard to catch high-hanging fruits if you're going to
ignore low-hanging ones.


Lucas Meijer-4 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
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> 

-- 
View this message in context: http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21975728.html
Sent from the Mono - Dev mailing list archive at Nabble.com.