What are the disadvantages of using P/Invoke

Question

I'm working already a good time with the .net framework. In this time there were some situations, I used P/Invoke for doing things that I couldn't do with managed code.

However I never knew exactly what the real disadvantages of using it were. That was also the reason why I tried not to use it as far as possible.

If I google, then I find various posts about it, some draw a catastrophic picture and recommend never to use it. What are the major drawbacks and problems of an app that uses one ore more P/Invoke-calls and when do they apply. (not of a performance perspective, more in the manner "could not be executed from a network share")?

Answer 1

1. Marshalling between managed/unmanaged types has an additional overhead
2. Doesn't work in medium trust
3. Not quite intuitive and could lead to subtle bugs like leaking handles, corrupting memory, ...
4. It could take some time before getting it right when looking at an exported C function
5. Problems when migrating from x86 to x64
6. When something goes wrong you can't simply step into the unmanaged code to debug and understand why you are getting exceptions. You can't even open it in Reflector :-)
7. Restricts cross platform interoperability (ie: you can't run under Linux if you rely on a Windows-only library).

Conclusion: use only if there's no managed alternative or in performance critical applications where only unmanaged libraries exist to provide the required speed.

Answer 2

There are three different scenarios where you use P/Invoke, and different disadvantages arise (or don't) in each.

1. You need to use a Windows capability that is not provided in the .NET Framework. Your only choice is P/Invoke, and the disadvantage you incur is that now your app will only work on Windows.

2. You need to use a C-style DLL provided to you by someone else and there is no managed equivalent. Now you have to deploy the DLL with your app, and you have the problems of marshalling time and possible screwups in your declaration of the function (eg IntPtr/int), string marshalling, and other things people find difficult.

3. You have some old native code that you wrote or control and you feel like accessing it from managed code without porting it. Here you have all the problems of (2) but you do have the option of porting it instead. I'm going to assert that you will cause more bugs by porting it than you will by P/Invoking badly. You may also cause a bigger perf problem if the code you're porting makes a lot of calls to native code such as the CRT.

My bottom line is that while P/Invoke is non trivial, telling people to avoid it is bad advice. Once you have it right, the runtime marshalling costs are all that remain. These may be less than the runtime costs you would get with porting the code.