[Mono-dev] Mixed Mode Assemblies

[David Mitchell]

As I understand it, Mono on Windows does support running mixed-mode
assemblies.

My guess is the primary reason for not supporting it on other platforms
has more to do with the hassle of developing a C++/CLI compiler than
concerns about cross-platform compatibility.


A long time ago, there was a mention on twitter of C++/CLI support being
added to Clang (https://twitter.com/#!/atoker/status/5830794151), but I've
not seen anything about it since then.

Personally, I'd love to see C++/CLI and mixed-mode assembly support, as it
would allow us to eliminate a lot of code (our Windows product uses
C++/CLI for part of the product, while Mac goes the P/Invoke route with a
lot of error-prone code duplication along the way).

However, I expect to find myself in the minority on this issue; I'm sure
there are many more issues to be addressed that would help a much greater
number of Mono users.

-- Dave

On 7/7/11 8:55 AM, "arkain" <kingmph at gmail.com> wrote:

>I understand the reasons why the developers chose to leave out support for
>developing mixed-mode assemblies using mono: the lack of cross-platform
>compatibility in such assemblies. However, I would argue that such things
>are not a consideration for those who would choose to develop such
>assemblies.
>
>Consider something. When a developer want's to do mixed-mode development,
>it's almost invariably because there is some functionality, usually in a
>platform-specific native library, that the developer want's access to in a
>.NET language. Likewise, when a developer wants to use P/Invoke, the same
>logic applies. That also means that the resulting assembly will be of
>little
>to no use unless all platforms that the assembly will be used on will have
>an appropriate version of the same native library available. In either
>case,
>it's up to the developer to be aware of such issues. I would no more
>expect
>a mixed-mode assembly to work cross platform than I would a native
>executable. Listing such as the reason to leave out this functionality
>denies the very reason why it was included in Microsoft's implementation.
>
>Without a doubt, every case where I've wanted/needed to use C++.NET has
>been
>to create a mixed mode assembly with the intent of creating a clean,
>optimized .NET interface for some piece of unmanaged code. If P/Invoke and
>System.Runtime.InteropServices formed a complete solution for importing
>native functionality into .NET, then I doubt Microsoft would have bothered
>allowing for mixed-mode assemblies at all. However, there are a great many
>things that cannot be cleanly handled using P/Invoke when it comes to
>importing library functionality. One such case I encountered was a library
>with functions that returned char* containing buffered data if it existed,
>NULL if no data existed, or -1 on error. With C++.NET, I separated the
>single return value into a return code and an out parameter, relieving me
>of
>the need to convert IntPtr's into 2 different things on the .NET side. I'm
>not claiming that this couldn't have been done without mixed-mode, but I
>am
>saying that the mixed mode-solution was superior. Things become even more
>interesting when the parameter list of the native function includes either
>(...) or (va_list). While .NET's params keyword helps, there's often a
>much
>more elegant solution that can be devised using mixed-mode code.
>
>Put in short, P/Invoke is just fine for importing a few functions every
>now
>and again, but when a native library of code needs to be exposed, nothing
>beats mixed mode using C++.NET. The absence of this functionality from
>mono
>is an oversight that most certainly should be corrected.
>
>--
>View this message in context:
>http://mono.1490590.n4.nabble.com/Mixed-Mode-Assemblies-tp3651901p3651901.
>html
>Sent from the Mono - Dev mailing list archive at Nabble.com.
>_______________________________________________
>Mono-devel-list mailing list
>Mono-devel-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-devel-list