C# DLL's plugin-architecture

Question

Tengo un programa que desarrollé para usar una arquitectura de plugins básica. Efectivamente, cuando el programa se carga, utiliza la función de reflexión para buscar en el directorio los dll que se ajustan a una determinada interfaz y luego los carga. Ahora parece que la lista actual de complementos es todo lo que se usará.

Por lo tanto, ¿mi práctica actual de verificar los archivos dll sigue siendo la mejor práctica o hay mejores formas de cargar cada dll?

Gracias.

Answer 1

Según su pregunta, parece que ha creado (o está intentando construir) su propio tipo de arquitectura de complementos. No es una buena idea, ya que .NET ya tiene lo que estás buscando.

.NET viene con 2 formas de permitir complementos.

1. System.AddIn
2. MEF - Gestionado extensibilidad marco

(1) System.AddIn - apenas he oído/leído mucho al respecto. Pero se puede echar un vistazo a algunos artículos aquí:
System.Addin article from MSDN magazine < - Nota del Año 2007
System.Addin tools and examples at Codeplex

(2) Ahora, el MEF, el MEF es simplemente impresionante! Es una forma genial y fácil de introducir una arquitectura de complemento en su sistema. MEF también es parte de Silverlight y Visual Studio 2010 lo usa. Veo que quiere cargar dlls con complementos dinámicamente, con MEF puede diseñar su aplicación de forma que las clases que empaqueta con su software puedan estar en su propio ensamblado (.exe) y luego puede usar MEF para buscar dinámicamente dlls en el futuro que tendrán las clases que necesita. Todo el procedimiento en sí es muy simple en MEF.

Mike Taulty has a brilliant video series on MEF

MEF Article at Codeproject - Part 1 MEF Article at Codeproject - Part 2

MEF is Open Source on Codeplex

yo personalmente creo que debe ir con MEF, su nuevo estudio, fácil e incluso visual utiliza, incluso para que pueda echar un vistazo en:
Choosing between MEF and MAF (System.AddIn)

Do check out other top voted questions on the mef tag at SO

Answer 2

Puede usar la clase FileSystemWatcher para supervisar un directorio en busca de cambios.

publicvoid CreateWatcher() 
{ 
//Create a new FileSystemWatcher. 
FileSystemWatcher watcher = newFileSystemWatcher(); 

//Set the filter to only catch DLL files. 
watcher.Filter = "*.dll"; 

//Subscribe to the Created event. 
watcher.Created += new 
FileSystemEventHandler(watcher_FileCreated); 

//Set the path to C:\Temp\ 
watcher.Path = @"C:\Temp\"; 

//Enable the FileSystemWatcher events. 
watcher.EnableRaisingEvents = true; 
} 

entonces se convierte en un asunto de plug and play :)

Answer 3

se refieren a MEF Es una solución arquitectónica muy potente para la creación de diseños plugin.

Answer 4

Esto es bueno. Alternativamente, puede definir qué ensamblajes se cargarán en el archivo de configuración también, si siente que tener numerosas DLL en dicha carpeta podría afectar su aplicación y podría haber algún problema de seguridad ya que cualquiera podría insertar una DLL en esa carpeta.

Answer 5

• Desde el plugin media: "usted donot conocer la DLL para cargar con antelación" No hay manera de primeros THS consolidan "desconocido-DLL" hay que cargar y buscar implementación de la interfaz y el uso de una especie de enlace tardío.
• "Buscar en el dll" en lugar de "editar un archivo de configuración" es muy fácil de usar. en la mayoría de los casos, la búsqueda de archivos DLL no es un problema de rendimiento, ya que se realiza solo una vez al inicio del programa.

Creo que su diseño está bien.

Answer 6

Para su escenario, recomiendo usar MEF y su DirectoryCatalog para cargar complementos desde una carpeta en particular. Si además configura el vigilante del sistema de archivos y actualiza DirectoryCatalog en el cambio de carpeta, gracias a la función de recomposición de MEF, ¡podrá obtener nuevos complementos en tiempo de ejecución! Por cierto, puedes ver un nice recomposition sample I did for one of my MEF talks.