Plugin / architettura modulare: problemi di distribuzione

Vorrei adottare un approccio secondo cui le librerie condivise sono responsabili del core e che i moduli possono essere aggiornati come vogliono su base individuale, tranne quando ciò richiede un aggiornamento a una libreria condivisa.

Inoltre, vorrei tenere traccia delle versioni delle librerie mantenendo un numero di versione singolo per la piattaforma principale che viene incrementato ad ogni release e facendo in modo che i moduli sappiano quale versione core richiedono. Ciò renderebbe più semplice il rilevamento dei problemi relativi alla corrispondenza errata.

Il vantaggio di questo è che lo sviluppo dei moduli può continuare per lo più indipendentemente dalla piattaforma principale e l'un l'altro, si spera che solo con gli aggiornamenti occasionali richiesti al core.

Finché sei l'unico fornitore per tutti i "plug-in" e finché i moduli non hanno bisogno di centinaia di spazio su disco MB, ti suggerisco di mettere sempre tutte le DLL in ogni pacchetto rilasciato e trattare tutto come un unico prodotto, con un numero di versione. Ciò semplifica la distribuzione, poiché non è necessario disporre di pacchetti separati per gli aggiornamenti parziali e, se è necessaria una reinstallazione completa della versione più recente, è possibile utilizzare esattamente lo stesso pacchetto.

Tuttavia, se si utilizzerà l'architettura dei plugin per consentire ai moduli di ottenere il proprio ciclo di vita, in gran parte indipendenti dal core, pianificare i moduli come se fossero forniti da un altro fornitore. Assicurati che ci sia un'interfaccia stabile tra i moduli e il core e assicurati che le librerie dei moduli non entrino in collisione con le librerie del core (ad esempio, evita di installarle nella stessa cartella). Anche se hai una libreria condivisa che viene utilizzata nel core e riutilizzata in uno dei tuoi moduli, assicurati che il core e i moduli possano usare simultaneamente diverse versioni di quella libreria condivisa. E assicurati che il tuo prodotto e i tuoi moduli abbiano i loro numeri di versione. Quindi puoi distribuire il tuo core e i tuoi plugin separatamente.

La seconda opzione in genere richiede più sforzo nella gestione della configurazione rispetto alla prima, quindi solo "perché hai un'architettura plug-in e puoi trattare i tuoi moduli come prodotti diversi" non significa che devi farlo e perdere qualcosa di importante quando distribuisci tutto in un unico pacchetto.

Tre opzioni per te, scegli quella che ti piace di più:)

1. Inietti qualsiasi dipendenza dal framework

   Quando il tuo framework istanzia il plugin, dovrebbe passare qualsiasi API framework necessaria al plugin come interfacce iniettate. In questo modo puoi essere certo che il plug-in stia utilizzando una versione compatibile con il tuo framework.

2. Utilizza l'isolamento del processo

   Crea un'istanza di ciascun plug-in nel proprio processo. Anche se questo può sembrare eccessivo ridicolo, è anche dannatamente a prova di proiettile. Anche se il plug-in si blocca completamente, non eliminerà il tuo framework. È anche possibile avviare ciascun plug-in in un contesto utente diverso, che può anche aiutarti a proteggerti da plugin dannosi (vedi Principio di privilegio minimo ). Questa opzione consentirà ai plug-in di funzionare con versioni diverse delle stesse DLL e consentirà anche versioni diverse del framework .NET.

3. Richiedi la certificazione del plugin

   Tutti i plugin devono essere inviati a un server (può essere automatizzato, se lo desideri) che "certifica" che la DLL è compatibile con il framework (magari con alcuni test di base automatizzati). Dopo che il plug-in è stato convalidato, può essere strongmente denominato e firmato con la tua chiave privata in modo che il framework possa dire se è stato manomesso. Modifica il tuo framework per consentire solo i plug-in firmati.