different behaviors of mixed-mode assembly under .net/wine-mono/native mono.

[Vincent Povirk]

> So I have a specific question - how do I go about finding
> out how the IL code exception comes about?
> (I have had a couple of patches in either camp so
> I am not against patching wine or mono, or wine-mono for that matter)

You can set the WINE_MONO_VERBOSE environment variable to a single
digit greater than 0 to get debugging information related to JIT
compilation. This should at least tell you exactly which method's IL
is being rejected.

Setting MONO_VERBOSE_METHOD will show debugging information for the
JIT compilation of a specific method, unfortunately Mono crashes
trying to parse many of the mangled names that appear in Managed C++
assemblies, so often this approach does not work for me. I've often
had to hack the code that checks MONO_VERBOSE_METHOD to special-case a
specific method name.

> And a general question: are mixed mode assemblies supposed
> to work under win32 mono at all, or wine-mono definitely needed?
> I saw some wine + mono discussions a while ago and
> I got the impression that mixed mode assemblies are supposed to
> work with win32 mono somewhat?

There is some support for mixed-mode in win32 mono, but it is disabled
by default. They are different enough that I would not use win32 mono
on Windows to learn anything about how well wine-mono "should" work.

> The application itself is available as a public download in binary form.
> But since it mostly works - correctly under .net, and even the
> illegal IL exception was caught, just not the null constructor.
> Editing the IL code to put a try+catch around the constructor
> makes it largely operational too under linux mono, so there is
> not much of a bug to file; mostly a curiosity why
> wine-mono doesn't behave like it support mixed-mode fully, or
> not at all, but something between.

Microsoft's managed C++ compiler has been known to generate IL that
technically violates ecma 335, or otherwise gives Mono trouble. We
have hacks in wine-mono for a few of these cases, but it's likely we
have not addressed all of them.

There are also features used by managed C++, such as "thiscall"
reverse-pinvokes, which are technically independent of mixed-mode, but
which are not implemented in wine-mono.