Tra il leggere, l'immagazzinare informazioni e poi usarle, come al solito di differenza ce ne passa un oceano.

Oggi stavo da un cliente che mi ha chiamato per delle consulenze (ok, si mi sono rimesso a lavoro - ho ancora un sacco di difficoltà, ma spero di superarle a breve) e mi espone - tra le varie perplessità - "Sai vorrei creare una dll da riclicare per dei progretti proprio come facevo per VB6". Al che prima cosa che mi viene in mente è GAC ... e gli spiego cosa è ... a cosa serve, come fare per registrare i componenti all'interno ecc. ecc.
Devo premettere tuttavia che nemmeno io ne avevo mai sentito la necessità, perchè non essendoci più il famoso Dll Hell Incovenient, onestamente se mi serviva una dll semplicemente la includevo nel progetto impostando la proprietà "Copy in locale folder" all'occorrenza.
Tuttavia nella vita bisogna provare tutte le esperienze e allora ho provato. Con grande rammarico ho scoperto che la Gacutil si limita a copiare la Dll e registrarla per l'ambiente di produzione, ma se ne sbatte altamente delll'ambiente di sviluppo.
Sulle prime sono rimasto di stucco. Certo, da un punto di vista ha ragione, d'altronde la Gacutil serve proprio per il deployment dell'applicazione e non può - e non deve sapere - che chi la sta usando ha magari installato una copia di Visual Studio sulla macchina. Però che diavolo, allora qui ad essere tordo è l'ambiente di sviluppo e di questo ne sono veramente contrariato. Ma come, un regsvr32 di vb ti registrava la dll e visual studio 6.0 andava a refreshiarsi i riferimenti e un ambiente di sviluppo nato (parlo di VS 2005, quindi potrei tollelarlo ancora su un 2003) quasi 5 anni dopo non ci riesce?!?!
Ma la cosa ancora più terrificante, a mio giudizio, è che nesseuno fino ad oggi sembra essersene lamentato. Cioè, ho trovato post su post che spiegavano come fare per risolvere il problema, ma una posizione ufficiale da parte di Microsoft che dicono stiamo preparando la fix no. E' sconcertante.

Comunque per ogni povero altro disgraziato che dovesse capitare nello stesso problema, segnalo a mia volta il http://support.microsoft.com/kb/306149link ufficiale dove Microsoft spiega come risolvere il problema.

Tuttavia ci tengo a sottolineare una grande "stronzata" che secondo me succede usando questo sistema. Se infatti si nota bene nell'elenco degli add reference la dll aggiunta nella gac, si potrà vedere che il link al quale fa riferimento è quello della cartella temporanea nella quale si è scelto di mettere tutti i propri assembly e non quello della GAC stessa.
Questo significa che se uno si dimentica, dove aver fatto di nuovo gacutil per rimpiazzare la dll vecchia con quella nuova, di copiarla anche nella cartella data in pasto alla chiave di registro del workaround, si ritroverà ad importare nel progetto una dll non aggiornata, andando così incontro a non oso immaginare quanti problemi.
Escludo poi fortemente - anche se nessuno lo vieta e forse questa è la vera strada da percorrere - di andare a mettere nel path della chiave di registro il percorso completo della GAC, altrimenti sarebbe da diventare scemi ogni volta; tuttavia mi preme sottolineare come lo stesso articolo di MS dice "your assembly folder" e comunque non fa allusione alla cartella GAC_MSIL dove invece l'assembly viene copiato in una sottocartella con il nome prescelto per la registrazione.

Sarò un profano in confronto a molti di questo blog ... e ho tanto tanto da imparare ... ma fischio perdersi in un bicchiere d'acqua.