Come implementare correttamente i plugin in C#?

Question

Sto cercando di aggiungere plug-in per il mio gioco e quello che sto cercando di attuare è questo:

• plugin sarà o mio o terzo partito quindi vorrei una soluzione in cui crash del plugin sarebbe non significa arresto anomalo dell'applicazione principale.

• I metodi dei plugin sono chiamati molto spesso (ad esempio a causa del disegno di oggetti di gioco).

Quello che ho trovato finora:

• 1) http://www.codeproject.com/KB/cs/pluginsincsharp.aspx - concetto semplice che sembra che dovrebbe funzionare bene. Poiché i plug-in sono utilizzati nel mio gioco per ogni round, è sufficiente aggiungere il metodo Restart() e se un plug-in non è più necessario, il metodo Unload() + GC dovrebbe occuparsene.

• 2) http://mef.codeplex.com/Wikipage - Managed Extensibility Framework - il mio programma dovrebbe funzionare su .NET 3.5 e non voglio aggiungere nessun altro framework separatamente Voglio scrivere il mio sistema di plugin da solo. Quindi questa soluzione è fuori discussione.

• 3) Microsoft fornisce: http://msdn.microsoft.com/en-us/library/system.addin.aspx ma in base ad alcuni articoli che ho letto è molto complesso.

• 4) AppDomain diversi per i plug-in. Secondo Marc Gravell (Usage of AppDomain in C#) diversi AppDomain consentono l'isolamento. Lo scarico di plugin sarebbe facile. Quale sarebbe il carico di prestazioni? Ho bisogno di chiamare metodi di plugin molto spesso (per disegnare oggetti per esempio).

  • Utilizzando domini applicazione - http://msdn.microsoft.com/en-us/library/yb506139.aspx

  • A few tutorials on java2s.com

la prego di commentare i miei risultati? Nuovi approcci sono anche benvenuti! Grazie!

Answer 1

È possibile definire un'interfaccia pubblica che deve essere implementata dal plug-in. Quindi con l'uso della reflection è possibile scansionare una cartella "plugin" per qualsiasi classe che implementa quell'interfaccia, quindi creare un'istanza di quella classe.

Dal tuo codice basta lavorare sull'interfaccia e chiamare il metodo necessario. A proposito di crash, assicurati sempre che le chiamate all'interfaccia "plugin" siano sempre incapsulate in un blocco try/catch. Se si verifica un'eccezione si può sempre disporre il plugin

Answer 2

Il "secrect" generalizzato di estensibilità NET è: Il caricamento dinamico (per ottenere il plugin nel dominio di applicazione), Reflection (per verificare che supporta i metodi/interfaccia specificata) , Attributi (per ottenere Meta-Dati per cose come il versioning), Late Binding (per usare effettivamente il plugin).

Se le vostre esigenze di estensibilità sono molto semplici o molto uniche, dovreste considerare l'implementazione a modo vostro.

Answer 3

Ho utilizzato this tutorial come base per la mia architettura plug-in un paio di anni fa.Credo che l'architettura fosse un'architettura relativamente semplice, ma ho riscontrato alcuni problemi quando si trattava di passare messaggi tra i plug-in.

Se sei intento a scrivere la tua architettura, allora è abbastanza giusto, ma vorrei mettere in guardia contro di esso. Non è un'impresa da poco, e prima o poi ti imbatterai in alcune importanti considerazioni di progettazione, come il passaggio di messaggi, che non sono banali da risolvere (ammesso che siano simultaneamente abbastanza interessanti e frustranti). C'è un enorme valore nell'usare qualcosa come MEF che risolve questi problemi per te, e fornisce una API e una struttura davvero belle su cui puoi costruire i tuoi plug-in.

Inoltre, MEF finirà per essere distribuito come parte della vostra applicazione, quindi non è necessario che i vostri utenti lo scarichino separatamente; è una dipendenza "invisibile" per quanto riguarda loro, e una leggera per gli sviluppatori, incluso te stesso. È anche l'architettura plug-in ufficiale per Visual Studio 2010, quindi ha un sacco di peso nella comunità .NET, e ci saranno sempre più sviluppatori in grado di scrivere plug-in per la tua app se lo usi anche tu.

Spero che abbia un senso.

Answer 4

ho sospetta che il duplice esigenza di:

1. prestazioni veloci con oggetti di disegno e
2. un incidente plugin non potrebbe andare in crash la vostra applicazione

stanno per conflitto.

Per assicurarti che un plug-in con bug non blocchi la tua app, devi caricarla in un AppDomain separato (come hai già identificato). Ma stai andando a prendere un colpo di prestazioni, come l'intero punto di AppDomains è che isolano le istanze di oggetti. Quindi, come minimo, devi serializzare argomenti ai tuoi plugin (possibilmente utilizzando oggetti MarshalByRef o Remoting). E sospetto che ciò significherà serializzare una buona parte del tuo stato di gioco (che sembra almeno una specie di immagine). Sul lato positivo, AppDomains vive nello stesso spazio del processo, quindi il sovraccarico non è così grave come la comunicazione tra processi.

Scaricare i plug-in è semplice come scaricare AppDomain.

Poiché è necessario serializzare gli argomenti, è possibile eseguire la convalida dello stato del gioco dopo che il plug-in è stato elaborato.

Ho fatto un po 'di giocherellare con AppDomains una volta. Ci vogliono alcuni secondi per costruirne uno, nella mia esperienza. Ciò potrebbe influire sul numero di plug-in che carichi in ogni AppDomain.