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