c++-cli - run - unit test.net core

Soporte C++/CLI en.Net Core

Question

Nuestra estructura de proyecto es como,

native.dll : - Este contiene código nativo puro escrito en c / c ++. Este archivo Native.dll expone algunas funciones usando el archivo * def.

Wrapper Library(wrapper.dll compiled with .Net framework v4.0) : - Para usar la funcionalidad de native.dll , se native.dll una Wrapper lib(wrapper.dll) en C++/CLI usando :clr/oldsyntax . Esta envoltura tiene todo el código de Interoperability y Marshalling .

Application(Console App v4.0) utiliza directamente wrapper.dll para usar la funcionalidad proporcionada por native.dll .

Ahora este proyecto necesita ejecutarse en .Net Core . Esto significa que tendremos una .Net Core application que hará reference wrapper.dll que, a su vez, hará referencia a native.dll .

Sé que esto no funcionará directamente. ¿Pero el problema es si .Net Core (CoreCLR) es compatible con el entorno de tiempo de ejecución C ++ / CLI (clr / oldsyntax) ?

Si no, ¿cuáles pueden ser las posibles soluciones para esta aplicación?

Answer 1

¿Si .Net Core (CoreCLR) es compatible con el entorno de ejecución C ++ / CLI (clr / oldsyntax)?

Que yo sepa, no hay ningún plan para admitir C ++ / CLI con .NET Core .

Si no, ¿cuáles pueden ser las posibles soluciones para esta aplicación?

Puedes (deberías) proporcionar una API de C Mono, por ejemplo, es compatible con P / Invoke y .NET Core también es compatible con P / Invoke (consulte también esta pregunta de desbordamiento de pila y este ticket relacionado con DllMap ).

Answer 2

Otra solución potencial (aunque, obviamente, es una tarea bastante difícil) si desea mantener C ++ (es decir, exponer una interfaz OO a .NET) podría ser echar un vistazo a CppSharp desde el proyecto mono. Es capaz de exponer el código C ++ nativo a través de un contenedor C # generado automáticamente. Es compatible con Windows, Linux, así como OSX. Sin embargo, no sé si el código generado puede compilarse a un objetivo estándar de .NET (no lo intenté). Solo puedo suponer que lo haría porque el código generado no utiliza ninguna API sofisticada (es básicamente un código de interoperabilidad y de clasificación); y, por cierto, también es posible personalizar el proceso de generación (aunque, una vez más, probablemente no sea una tarea fácil).