Why is COM interaction preferable to P / Invoke in .NET?

Question

In our project, we reuse a lot of Delphi code through COM in our asp.net application.

Like this: legacy delphi dll => delphi COM wrapper => .Net interop => asp.net (mvc)

We have some problems related to access violations, unloading dll, etc. Now I have ported some to use the obsolete dll directly through the P / Invoke code.

When I look at resources on COM and P / Invoke, people are almost always advised to use COM. Why is this? Does P / Invoke work with the following benefits:

• verification code will always use the correct dll instead of the last registered COM
• Several versions can work side by side on servers (for example: DEV, TEST and QA)
• No COM Registration Failures
• Much faster than COM communications (read articles indicate a 30% increase in speed)

Answer 1

Pinvoke is a very good tool, but it cannot replace COM. Pinvoke only supports simple functions with C. syntax. COM allows you to implement an object model. Take, for example, the classes in the Microsoft.Office.Interop namespaces, all of which are pure shell-free COM classes. Office interaction with pinvoke would be painfully painful.

Another major problem with pinvoke is that client programmers usually write declarations. The person with the least probability understood them correctly. A COM author can publish an automatically generated type library that is very similar to metadata in a .NET assembly. Significantly eliminating the chances of errors and the lack of the need for a client programmer to work outside of Project + Add Reference.

Addressing your bullets:

• verified code will always use the correct dlls instead of the last registered COM
  You are still subject to the vagaries of Windows finding the correct DLL. The only good way to avoid crashes is to store the DLL in the same directory as the EXE. Which is entirely possible in COM, all you have to do is create an empty file called yourapp.exe.local

• Several versions can work side by side on servers (for example: DEV, TEST and QA)
  Also no problem in COM using the above technique or using the reg-free manifest

• No more problems registering COM
  Use a non-registration manifest, so registration is not required. This is very easy to do, just set the Isolated property of the link to True.

• Much faster than COM communication (the articles I read show a speed increase of 30%)
  This is much slower than COM. You can incur additional costs by making late-call COM calls through IDispatch, which is about as expensive as using Reflection to make a call.

---

There is a third way to interact with native code: writing a wrapper of managed classes in C ++ / CLI. This method is widely used in the .NET environment, especially in mscorlib.dll, System.Data, and PresentationFramework, assemblies that are highly dependent on native code. However, it is not very suitable for Delphi; it works best for native code, which can be easily called from C or C ++.