¿Por qué se prefiere la interoperabilidad de COM sobre P/Invoke en .NET?

Question

En nuestro proyecto estamos reutilizando muchos códigos Delphi a través de COM en nuestra aplicación asp.net.

De esta manera: el legado Delphi dll => Delphi COM envoltorio => .Net interoperabilidad => asp.net (MVC)

Tenemos algunos problemas con respecto a violaciónes de acceso, descarga de DLL, etc ... tengo ahora portado algunos para usar el DLL heredado directamente a través del código P/Invoke.

Cuando miro los recursos con respecto a COM y P/Invoke, las personas casi siempre aconsejan usar COM. ¿Porqué es eso? ¿No P/Invoke tiene los siguientes beneficios:

• marchamos código siempre utilizará el DLL correcta del lugar del último COM registrada
• Múltiples versiones pueden correr al lado del otro en los servidores (por ejemplo, : DEV, TEST y QA)
• No más registros COM molestia
• mucho más rápido que la comunicación COM (artículos que leí indican un aumento de velocidad del 30%)

Answer 1

Pinvoke es una herramienta muy agradable pero sin duda es norte o sustituir a COM. Pinvoke solo admite funciones simples con una sintaxis de C, COM le permite implementar un modelo de objetos. Tome las clases en los espacios de nombres de Microsoft.Office.Interop, por ejemplo, todas son clases COM puras sin envoltorios. Hacer la interoperabilidad de Office con pinvoke sería insoportablemente doloroso.

Otro problema central con Pinvoke es que normalmente es la carga del programador cliente escribir las declaraciones. La persona con menos probabilidades de hacerlas bien. Un autor COM puede publicar una biblioteca de tipos generada automáticamente, al igual que los metadatos en un ensamblado .NET. Elimina drásticamente las probabilidades de errores y el programador cliente no necesita trabajo más allá de Proyecto + Agregar referencia.

Abordar las balas:

• sacados código utilizará siempre en lugar de la DLL correcta de la última COM registrada
  Usted está aún sujeta a los caprichos de la de Windows para encontrar el archivo DLL adecuada. La única buena manera de evitar accidentes es almacenar el archivo DLL en el mismo directorio que el EXE. Que es bastante posible en COM, así, todo lo que tiene que hacer es crear un archivo vacío con el nombre yourapp.exe.local

• Múltiples versiones pueden correr al lado del otro en los servidores (por ejemplo: DEV, TEST y QA)
  no es un problema en el COM o bien, mediante la técnica por encima o mediante el uso de un libre-registro se manifiestan

• no más registros COM molestaban
  usar un manifiesto sin reg lo que no requiere registro. Muy simple de hacer, simplemente establezca la propiedad Aislada de la referencia en True.

• Mucho más rápido que la comunicación COM (artículos que he leído indican un aumento de velocidad del 30%)
  Es mucho más lenta de COM. Puede incurrir en un costo adicional al realizar llamadas COM con destino tardío a través de IDispatch, que es más o menos tan caro como una llamada pinvoke.

---

Hay una tercera manera de hacer interoperabilidad código nativo: escribir un envoltorio clase administrada en el lenguaje C++/CLI. La técnica se usa mucho en .NET Framework, particularmente en mscorlib.dll, System.Data y PresentationFramework, ensambles que tienen fuertes dependencias en el código nativo. Sin embargo, no muy adecuado para Delphi, funciona mejor para el código nativo que se puede llamar fácilmente desde C o C++.