[Mono-dev] Mixed Mode Assemblies

arkain kingmph at gmail.com
Thu Jul 7 11:55:58 EDT 2011


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.


More information about the Mono-devel-list mailing list