.Net y arquitecturas de complementos

Question

A continuación de las discusiones de Jeff y Joel sobre arquitecturas de complementos.

Los complementos en C++ (que utilizan dlls cargados en tiempo de ejecución) siempre son un poco molestos. Tienes que hacer un montón de trabajo de campo para habilitarlos y luego el complemento también debe escribirse en C++, a menudo incluso con el mismo compilador. Los objetos COM y ActiveX resolvieron algunos de estos problemas pero introdujeron algunos propios.
Luego agregar, digamos, una interfaz de python, a una aplicación de C++ es una gran cantidad de trabajo.

¿Estoy en lo cierto al pensar que todas las bibliotecas (o ensamblajes o lo que se llame) escritas en un lenguaje .Net siempre se pueden llamar desde otro lenguaje .Net? ¿Y pueden los objetos y tipos de datos transferirse automáticamente entre ellos?

Presumiblemente, dado que todos los lenguajes .Net también usan Winforms (o WPF) para la interfaz gráfica de usuario, el acceso de los complementos a la interfaz gráfica de la aplicación principal también es relativamente simple.

Lo siento si este es un punto bastante obvio que soy solo un programador de C++ anticuado. Pero la facilidad de reutilizar las bibliotecas existentes de C++ a través de C++/CLI me ha convencido de que C# /. Net podría valer la pena investigar más.

Edición - gracias, estaba buscando discutir si los complementos eran una razón para ir .Net. Ser capaz de escribir ironpython mientras mis usuarios comerciales pueden escribir un plugin simple en VB y los usuarios técnicos pueden crear algo inteligente en F # sin que yo haga más trabajo parecía una buena razón para cambiar de C++

Answer 1

Estoy en lo correcto al pensar que todas las bibliotecas (o asambleas o lo que usted llámelos) escrito en un idioma .Net siempre se puede llamar desde otro idioma .Net? ¿Y pueden los objetos y tipos de datos transferirse automáticamente entre ellos?

Sí. En .NET, la compatibilidad entre idiomas es posible gracias a CTS (ofrece un conjunto de tipos de datos comunes para usar en todos los lenguajes compatibles con .NET y asegura la compatibilidad de tipos) y CLS (define un conjunto de estándares mínimos para todos los compiladores de lenguaje .NET debe cumplir y garantizar la interoperabilidad del lenguaje). Durante la compilación, el compilador de idioma respectivo convierte un código fuente de cualquier lenguaje compatible con .NET en código de idioma intermedio. Como todo ensamblado .NET (EXE o DLL) existe como un lenguaje intermedio, pueden interoperar entre ellos. Todos los lenguajes compatibles con .NET utilizan los mismos tipos de datos y se representan solo como tipos .NET. Por lo tanto, si está utilizando int en C# o Entero en Visual Basic .NET, en IL se representa como System.Int32. [Source]

Answer 2

El problema principal con complementos en .Net no es la capacidad de invocar el código desde el dll del plugin (y de interoperar con él), sino de problemas de seguridad. Esos también se pueden resolver, puede ver aquí (los de la muestra que está vinculada también deben presentar un complemento de host + muy simple) How to create a Plugin Model in .NET with Sandbox?

Y para la interoperabilidad entre los lenguajes .Net, no hay ningún problema con eso.
Gui compartido: he hecho esto con Winforms, y no fue muy difícil, aunque no sé si también sería tan fácil en WPF, nunca lo intenté.

Answer 3

Sí, se puede lograr todos ellos a través Reflection

existen artículos sobre C# estructura de plug-in, como this one

Answer 4

Si busca bibliotecas de complementos en.NET, hay un par de opciones Soy consciente de:

• De Microsoft no es MEF
• de Novell (Mono) hay Mono.Addins

Ambos son de código abierto, por lo que se puede ver cómo crearon un entorno plug-in.