Utilizzo di assembly .Net con versione

Question

Nel nostro software di elaborazione ci stiamo spostando da una versione di un assembly esterno a una versione più recente. Mentre l'attività complessiva eseguita dall'assemblaggio è la stessa, l'API è radicalmente diversa e non è stata mantenuta la compatibilità con le versioni precedenti. L'API è responsabile dell'estrazione di dati da stazioni esterne che potrebbero essere in esecuzione con un'API nuova o vecchia corrispondente (anche senza compatibilità con le versioni precedenti). Non abbiamo alcun controllo del software nell'assemblaggio esterno o sulle stazioni esterne. L'assembly esterno non è fortemente firmato e il modulo nell'assembly ha lo stesso nome per entrambe le versioni.

Invece di mantenere due versioni del nostro software di elaborazione, vorremmo evolverlo in modo dinamico e utilizzarlo per contattare la vecchia versione o la nuova versione dell'assemblaggio esterno dipendente dalla stazione esterna. Siamo in grado di determinare se una stazione esterna supporta la nuova versione, quindi la scelta di " versione " può essere più o meno esplicito.

Quindi l'installazione è che abbiamo un assembly esterno ComLib.dll in due versioni. Possiamo fare riferimento alle due versioni dallo stesso assembly / progetto e come possiamo distinguere tra i due assembly quando si determinano i tipi ecc.

Supponendo che quanto sopra non possa essere fatto all'interno di un singolo assembly / progetto, potremmo implementare "adattatore" specifico per la versione; assembly, uno per ogni versione dell'assembly esterno (penso che abbiamo già interfacce e astrazioni sufficienti per questo) ma ci sono avvertimenti che dovremmo cercare o alcune impostazioni specifiche per evitare confusione di tipo / versione in fase di esecuzione (risoluzione dell'assembly / caricamento ecc.)? Sono sufficienti "fianco a fianco"? supporto nel runtime .NET per questa configurazione?

AGGIORNAMENTO: un'ulteriore svolta a questa domanda viene aggiunta solo per rendere le cose più interessanti. Sembra che l'assembly esterno carichi assembly aggiuntivi e utilizza file di configurazione esterni. Poiché le diverse versioni richiedono file di configurazione diversi e diversi assiemi aggiuntivi, ogni versione deve caricare in qualche modo anche gli assiemi aggiuntivi che corrispondono alla loro versione.

Mi sembra che ciò che vogliamo siano gli assembly di ogni versione da caricare con un "root" in una cartella separata che contiene il file di configurazione e gli assembly aggiuntivi. Ciò è possibile anche con il risolutore / caricatore di assiemi standard o dovremmo fare un po 'di magia e forse caricare gli assiemi manualmente (in AppDomain separati?) Per imporre "root". cartelle?

Answer 1

Un buon post sulle opzioni per questo può essere trovato qui: http: // kevin-berridge. blogspot.com/2008/01/two-versions-of-same-shared-assembly.html

Answer 2

Dici che questo codice è usato per comunicare con stazioni esterne. Perché non creare un servizio dal codice che comunica con le stazioni esterne? Tale servizio verrebbe chiamato dal tuo programma attuale.

Ciò consentirebbe di avere due versioni del servizio in esecuzione: una per la vecchia API e una per la nuova. Ogni servizio sarebbe nel proprio processo (o forse AppDomain), quindi potrebbe caricare le versioni degli assembly che gli piacciono. Durante il passaggio del programma principale da una stazione a un'altra, passeresti da un servizio a un altro man mano che la versione dell'API cambia.

Ciò avrebbe l'ulteriore vantaggio di isolarti dal tuo fornitore esterno creando una terza versione dell'API che non è retrocompatibile con le prime due.

Le prestazioni di questa soluzione potrebbero essere piuttosto elevate, in quanto il tuo programma principale potrebbe comunicare con i servizi su named pipe o addirittura con un trasporto in memoria. WCF può passare da un trasporto all'altro (bind), nella maggior parte dei casi senza modificare il codice.

Answer 3

È possibile firmare gli assiemi utilizzando ILMerge , quindi utilizza questa tecnica per fare riferimento a loro dallo stesso progetto.