Architettura plug-in in .NET

Question

Sto provando a implementare come un'applicazione plug-in. So che ci sono già diverse soluzioni là fuori, ma questa sarà solo la prova del concetto, niente di più. L'idea sarebbe quella di rendere l'applicazione principale dell'applicazione quasi priva di funzioni per impostazione predefinita e quindi far conoscere ai plug-in l'un l'altro, avendo loro implementare tutte le funzionalità necessarie.

Un paio di problemi nascono:

1. voglio i plugin in fase di esecuzione di conoscere l'altro attraverso la mia domanda. Ciò non significherebbe che al momento del codice non potevano fare riferimento agli assembly di altri plugin in modo che potessero usare le sue interfacce, solo che l'inizializzazione della funzione plugin dovrebbe essere sempre attraverso la mia app principale. Per esempio: se ho entrambi i plugin X e Y caricati e Y vuole usare le funzionalità di X, dovrebbe "registrare" il suo interesse attraverso la mia applicazione per usare le sue funzionalità. Dovrei avere una sorta di "dizionario" nella mia applicazione in cui memorizzo tutti i plugin caricati. Dopo esserti registrato per interesse nella mia applicazione, il plugin Y otterrebbe un riferimento a X in modo che potesse usarlo. è un buon approccio?
2. Quando si codifica il plug-in Y che utilizza X, ho bisogno di fare riferimento all'assembly di X, quindi posso programmare sulla sua interfaccia. Questo ha il problema del controllo delle versioni. Cosa succede se codifico il mio plug-in Y contro una versione obsoleta del plug-in X? Devo usare sempre un posto "centrale" in cui si trovano tutti gli assemblaggi, avendo sempre le versioni aggiornate degli assiemi?

Ci sono per caso libri che trattano specificamente di questo tipo di progetti per .NET?

Grazie

Edit: penso che la gente se si allontanano dai 2 domande che ho fatto. Posso dare un'occhiata a MEF e #develop, ma mi piacerebbe ottenere risposte specifiche alle domande che ho fatto.

Answer 1

Cerca nello spazio dei nomi System.AddIn. È un po 'più basso di MEF, e quindi dovrebbe darti l'esperienza di "implementalo da solo" che stai cercando.

Answer 2

Una volta eseguito utilizzando this example. L'ho adorato, ma era un paio di anni fa, penso che ora ci potrebbero essere soluzioni migliori. Finché mi ricordo che l'idea di base era che nel tuo programma ci fosse una classe astratta, i tuoi plug-in ereditavano quella classe e venivano compilati come DLL ... o qualcosa di simile usando Interfacce. Comunque quell'approccio ha funzionato alla grande per me. Successivamente ho aggiunto un filesystemwatcher in modo che potesse caricare quei plugin DLL mentre è in esecuzione.

To load an Assembly

To get the types the assembly exposes

Answer 3

C'è un buon libro sulla costruzione di quello che stai cercando: dissezione di un C# applicazione: interno SharpDevelop. Ecco un link: http://www.icsharpcode.net/OpenSource/SD/InsideSharpDevelop.aspx

L'applicazione SharpDevelop è completamente basata su plug-in e il libro parla di come l'hanno costruito, delle insidie ​​che hanno dovuto affrontare e di come l'hanno superato. Il libro è disponibile gratuitamente dal sito o puoi anche acquistarlo.

Answer 4

Suggerisco di esaminare MEF. Questo è un nuovo modo di fare plugin in .NET. Ad esempio, è il modo migliore di fare nuovi addin per VS2010. Non l'ho usato da solo, ma quello che ho visto sembra fantastico.L'aggiunta di questa come una risposta su sollecitazione degli altri :)

Answer 5

Circa i due problemi specifici esposti:

1) Non sono sicuro di quello che stai cercando di raggiungere, ma la mia ipotesi è che si desidera avere inizializzazione pigra delle funzionalità e caricamento forse pigro dei componenti aggiuntivi. Se questo è l'obiettivo, ciò che stai proponendo potrebbe funzionare. Quindi potrebbe funzionare in questo modo:

• Il plug-in Y fornisce un elenco di funzionalità che è necessario utilizzare (potrebbe essere eseguito ad esempio tramite un'implementazione specifica dell'interfaccia o tramite un manifest xml).
• Il componente aggiuntivo X implementa un'API che consente di inizializzare una funzione, con un metodo come Inizializza (featureId).
• L'applicazione host ottiene l'elenco delle funzioni richiesto da Y, carica/inizializza il plug-in X e chiama Inizializza per ciascuna funzione.
• L'applicazione host fornisce anche una() metodo GetFeature cui Y può utilizzare per ottenere un riferimento a un oggetto 'caratteristica', che verrebbe attuato in X.

Tuttavia, se il plugin Y ha accesso diretto all'X API, penso che non sia necessario avere tutta quell'infrastruttura per la registrazione delle funzionalità. Puoi solo accedere alle funzionalità di X utilizzando direttamente l'API X, e Y si prenderà cura dell'inizializzazione pigro di ciascuna funzione quando richiesto. Ad esempio, Y potrebbe semplicemente chiamare SomeXFeature.DoSomething() e l'implementazione di quella classe inizializzerà la funzione la prima volta che viene utilizzata.

2) Se l'API di un assieme cambia, qualsiasi assembly a seconda di esso potrebbe interrompersi. I plugin sono solo assiemi che dipendono da altri assiemi, quindi si romperanno. Ecco alcune cose che puoi fare per alleviare questo problema.

• Assegnare un numero di versione a ciascun plug-in. Questa potrebbe essere solo la versione di assemblaggio.
• Quando si carica un plug-in, assicurarsi che tutte le dipendenze possano essere correttamente soddisfatte (ovvero, tutti i plug-in da cui dipende devono essere presenti e disporre della versione richiesta). Rifiuta di caricare il plugin se le dipendenze non possono essere soddisfatte.
• Implementare uno strumento di gestione dei plug-in, da utilizzare per tutte le operazioni di installazione/disinstallazione del plug-in. Il gestore può controllare le dipendenze e segnalare errori durante il tentativo di installare plugin con dipendenze insoddisfatte o quando si tenta di disinstallare un plug-in da cui dipendono altri plugin.

Soluzioni simili sono utilizzate dal framework Mono.Addins. In Mono.Addins, ogni componente aggiuntivo ha un numero di versione e un elenco di componenti aggiuntivi/versioni da cui dipende. Quando si carica un componente aggiuntivo, il motore del componente aggiuntivo garantisce che vengano caricati anche tutti i componenti aggiuntivi dipendenti con le versioni corrette. Fornisce inoltre un'API e uno strumento da riga di comando per la gestione dell'installazione di componenti aggiuntivi.