Nelle installazioni delle mie applicazioni sui computer dei miei clienti, non utilizzo mai la GAC per le mie librerie, questo perché non sono abbastanza brava da garantire la Compatibilità fra le DLL che compilo oggi e quelle che compilerò fra un mese, quindi, mettendo le librerie in GAC rischierei di mandare in crash una applicazione perché la nuova libreria installata con una seconda applicazione ha qualche metodo o qualche classe diversa da quella delle applicazioni precedentemente installate.
Perciò, per chi come me pone tutte le classi base e gli helper comuni a tutti i programmi in una serie di DLL, consiglio l'uso della GAC nelle installazioni se e solo se siete così disciplinati da essere certi al cento per cento che una applicazione installata con la build 1.0 funzioni anche con la 2.0, oppure, siate così bravi da inserire il file di configurazione applicazione che indichi in modo specifico la versione della libreria da usare.
A livello di sviluppo software invece, la GAC è molto utile ed io la uso sul mio PC per tutte le librerie comuni alle mie applicazioni in fase di sviluppo, infatti in questo modo è possibile trovare tutte le librerie automaticamente caricate nel tab .NET della form di inserimento dei riferimenti invece di doverle andare a cercare nei meandri delle cartelle ove abbiamo annidato i nostri progetti. Inoltre quando modifico una libreria di base, basta ricompilare tutte le applicazioni e sono aggiornate con la nuova versione, inoltre immediatamente mi danno errore se ho combinato qualche disastro eliminando/rinominando metodi e classi e sicuramente mi accorgo subito se le modifiche alla DLL vanno a fare esplodere i programmi che le usano, soprattutto se sono così brava da utilizzare gli Unit Test.
Questa è la lista di alcune delle mie librerie installate in GAC, però, per far comparire le librerie in questa lista, non basta semplicemente registrarle in GAC, perché Visual Studio è un po' cattivello e per comporre questa lista, ha bisogno di una chiave sul registry che gli indica quali sono le cartelle su cui andare a leggere le librerie della GAC.
La chiave del registry in questione si trova sotto
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\
Come potete vedere è necessario creare una chiave su questa cartella, il cui valore contiene il percorso su cui si trovano le nostre DLL registrate in GAC. Lo script per creare questa chiave sul registry è il seguente:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\NomeAzienda.Nomechiave]
@="C:\\CartellaDelleDllInGAC"
Se osservate l'immagine, per la chiave relativa alle mie librerie, ho imitato Infragistics (impariamo da chi c'è da più tempo di noi) chiamando la chiave con il Nik della mia azienda, il tipo di dll (Win/Web) e la versione delle stesse. Il nome della cartella ovviamente è il path completo della cartella dove si trovano le DLL.
Visto che andare a modificare chiavi sul registry è qualcosa da fare con un po' di attenzione, per non dover registrare una per una tutte le cartelle dei miei progetti DLL, ho creato un unica cartella dove pubblico le DLL che registro in cache.
A questo punto, l'obiezione è "Ma che noia, copiare la libreria a manina sulla cartella e poi registrarla in GAC".
Per evitare le cose noiose i programmatori sono bravissimi e quelli di Microsoft hanno predisposto sui progetti di Visual Studio il necessario per darci una mano.
Ciò che possiamo usare per automatizzare queste operazioni sono i Post Build Events di Visual studio, in VB non li avevano messi nella versione 2003 (lo so lo so vi maltrattano), ma nella versione 2005 si sono resi conto che in VB non si fanno solo programmini da dilettanti quindi sono stati aggiunti, un pochino nascosti ma li trovate qui.
La finestra si apre con il tastino che ho evidenziato e permette di gestire sia cose da fare prima di compilare che cose da fare dopo. Le cose da fare prima potrebbero ad esempio essere l'aggiornare dei files di contenuti (magari gli help e altro) che non sono di nostra competenza e devono essere aggiornati automaticamente. Nelle cose da fare dopo invece una delle più utili è l'automatizzazione della pubblicazione, che può anche essere un mezzo per inserire in un area comune a tutti gli sviluppatori delle DLL aggiornate di un team, in modo che ciascuno possa scaricarle in locale e usarle.
Prima di vedere come fare a realizzare il tutto, vediamo anche la versione C# (un po' meno nascosta)
Per darci ancor più una mano, i programmatori di Microsoft ci permettono di inserire negli script che possiamo chiamare prima e dopo la compilazione, una serie di Macro per recuperare dati relativi all'ambiente e al progetto senza dover riscrivere tutto a manina. Basta fare click sul bottone Edit Post-Build e appare questa finestra:
Vi invito a curiosare e provare le varie opzioni per vedere l'effetto che fanno... Vediamo che cosa ho scritto io sul mio mini script:
call ..\..\publish.bat $(ConfigurationName) $(TargetName)
call è un comando batch della console, serve per chiamare un file batch da un altro file batch perché in realtà questi script non sono altro che dei Batch di comandi.
..\..\publish.bat è il nome del file batch in cui ho inserito i comandi per la pubblicazione, il motivo del ..\..\ è che quando viene eseguita la chiamata, il sistema ha come current directory la cartella bin\debug oppure bin\release, pertanto dobbiamo risalire 2 livelli per trovare il file batch (uno solo per tutti) con i comandi per la pubblicazione che io ho inserito nella cartella di progetto.
$(ConfigurationName) vale Debug o Release in base alla configurazione da noi scelta per la compilazione e ci aiuterà a comporre il nome della cartella ove si trova la dll da pubblicare.
$(TargetName) E il nome dell'assembly che ci servirà per costruire i dati per pubblicare e registrare in GAC la nostra libreria.
Ed ora, l'ultimo oggetto da esplorare, il file Batch publish.bat.
cd ..\..
call %windir%\system32\xcopy.exe bin\%1\%2.dll "C:\DllPublish\*.*" /s/e/v/y
call %windir%\system32\xcopy.exe bin\%1\%2.xml "C:\DllPublish\*.*" /s/e/v/y
call "%ProgramFiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /u %2
call "%ProgramFiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /i bin\%1\%2.Dll
Questo batch è stato creato in modo da essere generico, funziona copiandolo e incollandolo su un qualsiasi progetto di tipo DLL, vediamo in dettaglio che cosa fa:
cd ..\..
Questo comando sposta la current directory allo stesso livello del file batch
%windir%
il comando %nome% rileva una delle Environment Variables che sono visibili dalla console dei comandi digitando
c:\> SET
In questo caso leggiamo la cartella di installazione di Windows, per comporre il luogo ove si trova il comando xcopy.exe
bin\%1\%2.dll
Il comando %n viene sostituito dal parametro della linea di comando passato al Batch file quindi in questo caso componiamo il nome della cartella e il nome della dll (ES. bin\Release\Mylibrary.dll)
%ProgramFiles%
Questo comando, legge dove si trova la cartella Programmi del sistema per comporre il nome della cartella ove si trova l'utility di registrazione in GAC delle DLL
Dopo aver spiegato le cose strane, vediamo come il nostro batch:
- sposta la cartella corrente sulla cartella di progetto,
- copia la DLL e il suo file di documentazione XML (che servirà per avere l'intellisense quando faremo ad essa riferimento nei nostri progetti) nella cartella di pubblicazione da noi scelta.
- rimuove dalla GAC la DLL
- registra in GAC la DLL
Con questa serie di "Barbatrucchi", otteniamo di risparmiarci delle noiose operazioni nello sviluppo di progetti complessi, provo ad elencarne alcuni:
- Trasformiamo le nostre librerie di base in una suite di oggetti a nostra disposizione per tutti i progetti. (se volete un esempio di cosa mettervi dentro leggete Guarda, Senza Mani! ove abbiamo creato una struttura di librerie riusabili).
- Abbiamo le librerie sempre a disposizione nel tab .NET per farvi riferimento.
- Le nostre librerie in GAC sono tenute sempre aggiornate all'ultima versione.
- Aggiungere una nuova libreria al gruppo delle librerie pubblicate è questione di qualche click, dobbiamo copiare e incollare il file batch publish.bat sulla cartella di progetto e aggiungere la riga di comando al Post Build Event.
IMPORTANTE!
Perche una libreria possa essere registrata in GAC deve essere dotata di uno Strong Name, ovvero deve essere firmata con una Chiave Binaria, per farlo, andate a guardare il tab Signing delle proprietà di progetto (usualmente l'ultimo nello stesso luogo ove abbiamo trovato i post build events).
Prometto che farò un post in merito in seguito.
Spero di esservi stata utile, per qualsiasi errore o domanda, approfondimento, delucidazione, il modulo di feedback è in fondo al post.
Tags: GAC, Strongname