Axel Gallus said:
[...]
I had a glance over the Interoperability classes and possibilites at
msdn -
it sounds to me that it is a science on his own to make umanaged
code/dll's
accessible for .Net with PInvoke. It seems to be very time consuming.
Maybe someone of you is able to help me deciding weather to use .Net or
not
for a software as mentioned above.
One person's point of view...
My limited experience has been that using p/invoke is every bit as
tedious, complicated, and poorly-documented as you might suspect.
Emphasis on "poorly-documented". I have found very little *clear*
guidance on how to determine exactly how to describe an interface to
non-managed code, especially when it is anything more complicated than
passing some 32-bit values in and getting a 32-bit value back (using
things like structures, strings, other kinds of arrays, for example).
Looking at existing p/invoke definitions I can see that the basic
mechanisms are actually not that complicated. But without comprehensive
documentation, it's been very difficult for me to learn what the magic
incantations are in each case.
For what it's worth, I've found that in some cases, it's much faster and
easier for me to write a wrapper for non-managed code in C++. You can
write managed C++ code that calls non-managed libraries, and then define
your own mechanism for translating the results to managed code. This
isn't always trivial either, but you have complete control over the
process. Your other .NET code would reference the managed C++ assembly,
and would only see managed data types passed back to it by the managed
C++.
For that matter, you can write managed .NET code in C++ for all your code,
and then the p/invoke issues just go away. I don't recommend it, mainly
because managed C++ is not nearly as intuitive or easy to write as C# (and
possibly VB.NET...I haven't used VB with .NET, but I assume it is more
like C# than C++), and the Visual Studio IDE has much better built-in
support for writing C# code than C++ (for example, "Intellisense" which
gives you context-sensitive shortcuts to writing the code and interpreting
existing code). But it can be done, and the end result is basically the
same as if you'd done the code in C# and figured out all the p/invoke
stuff.
So even if you simply don't want to mess with p/invoke, you can still mix
managed and unmanaged code without too much trouble.
The bottom line for me: if you have a good reason to use .NET -- that is,
it has features you want to take advantage of -- having to use non-managed
code isn't a reason to shy away from it. You will certainly have to spend
some time learning the various mechanisms available for mixing managed and
non-managed code, but if you're doing anything reasonably complicated I
don't think the time you spend learning that will be significant (I
suspect that someone working full-time could spend no more than a week --
40 hours -- tracking down all the necessary information and learning the
various p/invoke techniques needed), and once you've learned it once, the
same techniques will apply and it won't be nearly as hard to use the
interoperability features in the future.
Once you know how to do it, defining an import from non-managed code ought
to only take a few minutes at the most. The most time will be spent in
the cases where you don't know how to define the import and you spend time
either trying to debug a problem when you thought you knew the right way,
or trying to find the right documentation to explain the technique when
you know you don't already know the right way. Those situations would
obviously be more than a few minutes, but they should occur less and less
frequently the more you use p/invoke.
Pete
