P / Invoke o C++ / CLI para envolver una biblioteca de C

Depende en gran parte de cómo se maneja la propiedad de la memoria. P / invoke puede ordenar punteros solo cuando la administración de memoria es una de un par de formas particulares, generalmente buffers asignados por el llamante. Si su API devuelve punteros (a través del valor devuelto o el parámetro out, no importa) y espera que se devuelvan a una función de destrucción más tarde... p / invoke hará la clasificación automática o le dará acceso directo al valor del puntero que necesita enviar más tarde, nunca ambos. So C++ / CLI se convierte en un enfoque muy deseable en ese caso.

Piense en P/Invoke como invocación de plataforma, ¿está llamando a algo como la API Win32 que es muy amigable con P/Invoke o necesita proporcionar enlaces. NET para una biblioteca no administrada?

Dado que la envoltura normalmente es muy delgada, una envoltura de C++/CLI no necesita que conozca específicamente C++/CLI. Lo que necesita saber se puede encontrar en la especificación del lenguaje , es una extensa documentación con muchos ejemplos. P / Invoke es más bien una característica agradable de tener para bibliotecas existentes más pequeñas bien establecidas, pero si la interfaz para llamar a esa biblioteca cambia, se encontrará con un problema. Con C++ / CLI todavía puede tener una interfaz pública administrada en su proyecto de C++/CLI que está expuesta para el código administrado y manejar los cambios en la API de C de esa manera más fácilmente.

Si quieres deshacerte del DLL extra siempre puedes probar ILMerge, pero no estoy seguro de si es capaz de manejar ensamblajes mixtos, (aparentemente no), pero parece que es posibilidad de vincular tanto gestionado como no gestionado *.archivos obj con el enlazador de PlatformSDK como este:

cl.exe /MD /c /clr Unmanaged.cpp
csc.exe /target:module /addmodule:*.obj Managed.cs
link.exe /DLL /LTCG /NOENTRY /CLRIMAGETYPE:IJW *.obj Managed.netmodule

C++/CLI será más fácil de depurar si tiene personal que sabe cómo depurar C++. Si no lo haces, podría ser mucho más difícil.

Sugeriría que la compensación aquí es entre la facilidad de uso para los consumidores de su conjunto interop versus la facilidad de mantenimiento para el propio conjunto. Si tiene un núcleo sólido de ingenieros sénior que están familiarizados con C++ y que pueden mantener el ensamblaje de manera confiable, será mucho más fácil para el resto de su equipo que no está familiarizado con código nativo para darles una interfaz totalmente administrada que se encarga de todo por ellos.

Por otro lado, si eres la única persona en la tienda con experiencia en C++, estaría muy recelosa de incrustar un módulo de C++ en el proyecto, en caso de que alguien más tenga que mantenerlo más tarde.

Para una API de este tamaño (~40 puntos de entrada totales), dibujaría la línea divisoria entre C++/CLI y P/Invoke en función de la cantidad de "mugre de archivo de encabezado" que tiene que duplicar en C#. Si es una cantidad pequeña (a modesta), P/Invoke está bien. Una vez que empiezas a duplicar un montón de .Archivos H en C#especially especialmente para cosas que no están expuestas en su API. NET might podría ser mejor usar C++ / CLI.

Muchas respuestas buenas aquí - otra perspectiva es el plan para la API C existente. Los argumentos para usar PInvoke incluyen:

• Necesita mantener una API de C para compatibilidad con otros consumidores C
• Debe mantener el código en C como es grande y la migración también lo es caro

Los argumentos para usar C++/CLI incluyen:

• desea mover la mayor cantidad de código posible al CLR

En este caso puede comenzar con C++ / CLI y luego muévase más y más a C#