source - ¿Qué framework de add-in/workbench es la mejor alternativa de.NET para Eclipse RCP?
plugins eclipse java (5)
Deberías echarle un vistazo al Visual Studio Shell. Está disponible tanto en modo integrado, donde la aplicación reside a lo largo del lado del estudio visual como un complemento o puede usar el shell en modo aislado donde el shell solo sirve como un marco básico para su aplicación solo, similar al shell Eclipse. Echa un vistazo a esta página web .
El shell de Visual Studio es robusto, rico en funciones y gratuito. Todavía no he hecho ningún desarrollo, pero lo he estado buscando para un próximo proyecto. Parece ser tan poderoso como un marco de plugins como Eclipse.
Estoy buscando un framework de aplicaciones basado en complementos que sea comparable al Eclipse Plugin Framework, que para mi mente simple consiste en:
- un marco de administración de plugins principal (Equinox / OSGI), que proporciona la capacidad de declarar extremos de extensión y luego descubrir y cargar complementos que sirven esos puntos finales. (Esto es diferente a la Inyección de Dependencia, pero la diferencia es sutil: la configuración está muy descentralizada, existen problemas de versiones, puede implicar un repositorio de complementos en línea y, lo que es más importante para mí, debería ser fácil para el usuario agregar complementos sin necesidad de saber nada sobre los archivos subyacentes de arquitectura / configuración)
- muchas capas de complementos que proporcionan un shell de entorno de trabajo básico con soporte de simultaneidad, comandos, hojas de preferencias, menús, barras de herramientas, enlaces de teclas, etc.
Eso solo está arañando la superficie del RCP, que a su vez está destinado a servir como base de su aplicación, la cual construye al escribir / ensamblar aún más complementos.
Esto es lo que obtuve de internet en los últimos días ...
Por lo que puedo decir, no hay nada en el mundo de .NET que se acerque remotamente a la solidez y madurez del Eclipse RCP para Java, pero hay varios contendientes que hacen bastante bien el # 1 o el # 2.
(También debo mencionar que no he tomado una decisión final sobre WinForms vs WPF, así que también estoy tratando de entender el nivel de acoplamiento de la interfaz de usuario en cualquier marco candidato. También me pregunto sobre el acoplamiento de plataforma y la licencia de código fuente)
Debo decir que las cosas de código abierto generalmente están menos documentadas pero son más fáciles de entender, mientras que las de MS suelen tener más documentación pero son menos accesibles, por lo que con muchas de las tecnologías de MS, me pregunto qué hacen en realidad. , en un sentido práctico.
Estas son las bibliotecas que he encontrado:
SharpDevelop
Lo primero que miré fue SharpDevelop, que hace # 1 y también # 2 de manera básica (no es un insulto para SharpDevelop, lo cual es admirable; me refiero a algo más básico que Eclipse RCP). Sin embargo, SharpDevelop es una aplicación más que un marco, y hay suposiciones y limitaciones básicas allí (es decir, estar unidas a WinForms). Aún así, hay algunos artículos en CodeProject que explican cómo usarlo como base para una aplicación.
System.Addins
Parece que System.Addins está destinado a proporcionar un sólido marco de carga complementario, con algunas opciones sofisticadas para cargar ensamblajes con diferentes niveles de confianza e incluso ejecutar el proceso fuera de proceso. Parece estar principalmente basado en código, y bastante pesado en código, con muchos ensamblajes que sirven para aislar contra problemas de control de versiones, utilizando la Automatización de Orientación para generar una gran cantidad de código.
Hasta ahora no he encontrado muchos artículos de System.AddIns que ilustren cómo podría usarse para construir algo así como un Eclipse RCP, y muchas personas parecen estar estrujando sus manos sobre su complejidad.
Mono.Addins
Parece que Mono.Addins fue influenciado por System.Addins, SharpDevelop y MonoDevelop. Parece proporcionar los conceptos básicos de System.Addins, con opciones menos sofisticadas para la carga de complementos, pero más simple, con registro basado en atributos, manifiestos XML y la infraestructura para repositorios de plugins en línea.
Tiene una buena cantidad de preguntas frecuentes y documentación, así como un conjunto bastante robusto de ejemplos que realmente ayudan a dibujar una imagen de cómo desarrollar una arquitectura como la de SharpDevelop o Eclipse. Los ejemplos usan GTK para UI, pero el marco en sí mismo no está acoplado a GTK. Parece que hace # 1 (carga adicional) bastante bien y señala el camino hacia # 2 (marco de trabajo). Parece que Mono.Addins se derivó de MonoDevelop, pero en realidad no he analizado si MonoDevelop proporciona un buen marco de trabajo central.
Managed Extensibility Framework
De esto es de lo que todos están hablando en este momento, y cada vez está más claro lo que hace, pero todavía estoy bastante confuso, incluso después de leer varias publicaciones en SO. La palabra oficial es que "puede vivir lado a lado" con System.Addins. Sin embargo, no hace referencia a él y parece reproducir parte de su funcionalidad. Me parece, entonces, que es una alternativa más simple y accesible a System.Addins.
Parece ser más parecido a MonoAddins en que proporciona cableado basado en atributos. Proporciona "catálogos" que pueden basarse en atributos o en directorios. No parece proporcionar ningún XML o cableado basado en manifiesto. Hasta ahora no he encontrado mucha documentación y los ejemplos parecen ser algo "mágico" y más una reminiscencia de la DI basada en atributos, a pesar de las aclaraciones de que el MEF no es un contenedor DI.
Su licencia acaba de abrirse, pero hace referencia a WindowsBase, no estoy seguro si eso significa que está acoplado a Windows.
Acrópolis
No estoy seguro de qué es esto. ¿Es MEF, o algo que todavía está por venir?
Bloques de aplicaciones compuestas
Hay bloques de aplicaciones compuestas WPF y Winforms que parecen proporcionar mucho más un marco de trabajo. Tengo muy poca experiencia con estos, pero parecen confiar bastante en la Automatización de Orientación, obviamente están acoplados con las capas de la interfaz de usuario. Hay algunos ejemplos de combinación de MEF con estos bloques de aplicaciones.
Hice lo mejor que pude para responder mi propia pregunta aquí, pero en realidad solo estoy rascando la superficie, y no tengo experiencia con ninguno de estos marcos. Con suerte, algunos de ustedes pueden agregar más detalles sobre los marcos con los que tienen experiencia. Sería genial si pudiéramos terminar con algún tipo de matriz de comparación.
Acabo de lanzar SoapBox Core como código abierto y escribí un artículo introductorio sobre CodeProject . Básicamente es lo que estás buscando. Utiliza MEF para la extensibilidad, y recibí muchas de las ideas de SharpDevelop. Tenga en cuenta que es completamente nuevo y sigue evolucionando rápidamente.
+1 para SharpDevelop. Las bibliotecas están bien escritas y son simples de extender. De hecho, estoy escribiendo mi propia aplicación de refactorización de código usando SharpDevelop Core y su infraestructura Addin.
Muy agradable.
-Doug
Puede ser considerado...
Si bien no estoy familiarizado con los detalles de RCP, creo que DxCore probablemente será el marco más completo para extender Visual Studio con código administrado. Utiliza una arquitectura basada en plug-ins y le brinda la capacidad de crear desde ventanas de herramientas (alojando el código que desee) hasta "Acciones" (elementos que pueden vincularse con accesos directos de teclado y menús contextuales) y refactorizaciones, con una gran riqueza sistema de contexto, y un motor de generación de código agnóstico de lenguaje. Proporciona una capa de abstracción muy agradable en la parte más vulnerable de Visual Studio. También está escrito para ser independiente de la versión, por lo que los complementos escritos en DxCore funcionarán para VS 2005 y VS 2008.
Si bien es gratis, no es de código abierto, y lamentablemente hay muy poca documentación. Tiene las muestras proporcionadas, que son un buen comienzo, pero aquí hay algunos otros recursos que podrían ser útiles:
- Mark Miller es el arquitecto de DxCore / CodeRush / Refactor Pro !, y tiene algunas publicaciones en su blog (y episodios de DNR TV ) sobre cómo escribir complementos DxCore.
- Hay un foro de la comunidad donde puedes publicar preguntas. Esto es seguido por Mark y algunos de los otros desarrolladores de DxCore, así como por algunos miembros de la comunidad
- Complementos DxCore en Google Code. Un intento de recopilar los complementos que ha creado la comunidad en un solo lugar. Esta es una buena mezcla de herramientas y refactorizaciones, aunque algunas están desactualizadas.
Espero que esto te sea útil. Lo único realmente malo que tengo que decir al respecto, y la razón por la que probablemente no se utilice más ampliamente es que es una biblioteca tan grande, con casi ninguna documentación, hay que estar dispuesto a excavar para descubrir cómo utilizar algunos de las características más frescas.
¡Buena suerte!