Come è noto, il Framework .NET ha portato un nuovo modo di gestire gli assembly, per evitare il cosiddetto DLL's hell (l'inferno delle DLL). Per anni windows ha sofferto degli effetti collaterali di instabilità dovuti alla sostituzione di una DLL, magari condivisa (cioè utilizzata da più applicazioni), a seguito dell'installazione di un nuovo software. Se la nuova versione della DLL non era compatibile con le precedenti versioni, una o più applicazioni potevano smettere di funzionare di colpo, apparentemente senza motivo.
Ecco perchè, quando compiliamo un assembly .NET, esso è identificato da quattro parti:
- Friendly name
- Version number (major version, minor version, build number, and revision number)
- Culture setting
- Public key or public key token
Però qui sembra sorgere un problema, perchè visto che il friendly name è proprio il nome del file senza l'estensione, il file system non è in grado di mantenere nella stessa directory più versioni con lo stesso friendly name. Inoltre sviluppatori software di diverse società potrebbero usare lo stesso nome per assembly diversi tra loro. Infine, di uno stesso assembly potrebbero esserci diverse versioni per ciascuna specifica cultura (lingua-nazione).
Ad esempio: se la società Gamma sviluppa una libreria per disegnare e la chiama HyperX, con versione 1.2.21.2 e un'altra società Epsilon sviluppa una libreria per analisi statistiche e la chiama anch'essa HyperX, con versione 2.5.2.1, una volta compilate entrambe avranno come nome file HyperX.DLL
Qui entra in gioco una doppia possibilità, offerta da .NET:
- Mettere tutte le nostre DLL nella cartella che contiene l'applicazione (o nelle cartelle contenute in essa)
- Utilizzare la GAC (Global Assembly Cache, spiegata molto bene nell' articolo di Fabrizio Baldazzi)
Nel primo caso questo consente il deploy dell'applicazione "a la Mac" (sempre che l'applicazione sia interamente managed, i.e. .NET 100%), ossia la possibilità di installare l'applicazione semplicemente copiando la cartella che la contiene, senza dover registrare componenti vari nel registro e altre amenità del "vecchio mondo com".
Nel secondo caso, volendo utilizzare la GAC, dobbiamo fare la build della nostra assembly firmandola con la classica coppia di chiavi pubblica/privata, eventualmente generata con l'utilità SN.exe.
E' importante notare che la chiave pubblica identifica l'autore dell'assembly, e non varia al variare delle versioni dell'assembly.
Il vantaggio di usare la GAC è quello di poter avere un sistema centralizzato (come quello delle DLL com) ma che consente di mantenere contemporaneamente più versioni di una stessa DLL utilizzando in modo a noi trasparente una struttura di sottocartelle.
In entrambi i modi, un'applicazione che è stata installata insieme alla versione 1.3.5.2 di HyperX.DLL della società Gamma non verrà minimamente modificata dalla successiva installazione di un'altra applicazione che usa la versione 1.3.5.2 (casualmente uguale alla precedente) di HyperX.DLL della società Epsilon.
Se in un momento successivo, una terza applicazione dovesse installare una versione aggiornata di un'assembly, questa versione NON cancellerebbe la DLL precedente, e le applicazioni precedentemente installate non utilizzerebbero la nuova DLL (Precisazione: usando la GAC la utilizzerebbero solo se la nuova DLL avesse le stesse major e minor version ma build number e revision number più recenti).
In questo modo chi sviluppa una nuova versione dell'assembly non deve preoccuparsi di mantenere la compatibilità con le versioni precedenti, e chi usa un'assembly può star sicuro che nessun'altra applicazione gli toglierà lo sgabello da sotto il sedere!
posted @ lunedì 21 gennaio 2008 04:03