Patching a caldo di un server: caricamento dinamico dei tipi da un assembly caricato

5

Nel progetto corrente su cui sto lavorando, alcune delle classi C # vengono archiviate come codice sorgente nei record del database SQL Server ed eseguite come necessario utilizzando CSScript . Questo viene fatto in modo che il server non debba essere rimosso per sostituire l'assembly in cui risiedono queste classi.

Sebbene ciò sia sembrato una buona idea in linea di principio, i costi di questo schema hanno superato i benefici su un certo numero di livelli, e ora sto cercando altri possibili rimedi.

In passato, quando avevo bisogno di questo tipo di "late binding", ho semplicemente usato Activator.CreateInstance() per creare un'istanza e utilizzare i tipi di cui ho bisogno. In genere, questa funzionalità viene nascosta dietro un metodo factory che utilizza un file di configurazione XML per cablare gli assembly appropriati.

Quindi, nel mio mondo perfetto, quando voglio applicare hot patch al server, copierò l'assembly sul server, modificherò il file XML per fare riferimento al nuovo assembly e quindi le istanze successive di quel tipo saranno richieste via il metodo factory, il server riceverà automagicamente le istanze dal nuovo assembly anziché quello precedente.

Detto questo, non l'ho mai provato con un sistema in esecuzione. L'ho sempre usato con un programma che non è in esecuzione, come una sorta di sistema di plugin per poveri. Sono a conoscenza di cose come MEF , ma non lo faccio sapere come si applica il MEF qui, dato che non ho mai dovuto usarlo.

La mia domanda è semplice: cosa mi manca? Non è così semplice come penso che sia? Questo fallirà perché non ho scaricato il dominio dell'app che la DLL originale da cui è stato caricato il tipo originale? Il mio algoritmo diventerà improvvisamente Skynet senza preavviso?

In breve, c'è un modo migliore?

    
posta Robert Harvey 14.07.2015 - 22:16
fonte

1 risposta

3

A seconda di cosa stai cercando di fare, è più semplice.

IIS riavvierà automagicamente il pool di applicazioni quando vedrà che un file è stato modificato. Se tutto quello che stai cercando di fare è un patch su un server in esecuzione, basta premere una nuova DLL e lasciare che il pool di applicazioni cicliche.

Will this fail because I haven't unloaded the app domain that the original DLL from which the original type was loaded?

Se la tua vecchia DLL e la tua nuova DLL hanno la stessa versione, sono abbastanza sicuro che faranno cose molto brutte. Mentre pensavo che i tipi con lo stesso nome completo ma versioni diverse suonassero bene - sembra che sia non è il caso .

what am I missing?

Una cosa di cui preoccuparsi è che il caricamento dalla configurazione tende ad essere un'operazione costosa - una che viene memorizzata nella cache, o dal codice o da alcune API sottostanti. Affidarsi alla fabbrica per vedere il nuovo obiettivo è probabilmente una fonte facile e rapida di bug sottili. Esistono anche problemi di concorrenza in cui il tuo codice può presumere che le chiamate consecutive a Factory.Create restituiscano lo stesso tipo concreto.

Ma alla fine, si ridurrà a Activator.CreateInstance .

    
risposta data 14.07.2015 - 22:50
fonte

Leggi altre domande sui tag