Quando abbiamo la necessità di riutilizzare la stessa versione di un componente che abbiamo scritto in più applicazioni, viene naturale pensare alla GAC (Global Assemby Cache). Essa presuppone che l'assembly che andiamo a mettere al suo interno sia Strong Named, ossia sia dotato di un nome univoco composto da:
- nome del file
- versione
- culture
- publik key (o hash della chiave)
Per fornire ad un assebly uno strong name, abbiamo bisogno di una coppia di chiavi (pubblica e privata) ottenibili dal tool da riga di comando SN.EXE con le quali poi "firmeremo" il file "assicurandone" tra l'altro l'identità.
I termini "firmeremo" e "assicurandone" sono messi tra virgolette in quanto, è importante sottolinearlo (come ripete sempre l'amico Raf), lo Strong Name è uno strumento di Versioning e non di Security!
Ma non voglio divagare sul discorso Strong Name in sè (magari ne parlo in un altro post), e preferisco tornare all'oggetto del post: Deley Signing.
Partendo dal presupposto che lo strong name *dovrebbe* assicurarne l'identità dell' assembly firmato, e che per firmare l'assembly abbiamo bisogno di una chiave privata, ha senso, all'interno di un team, dare agli sviluppatori la chiave privata per la compilazione e la firma degli assembly durante la fase di sviluppo? La risposta è ASSOLUTAMENTE NO!
Ed allora, come facciamo?
Il .NET Framework supporta un meccanismo chiamato Delayed Signing che permette di firmare l'assembly usando la sola chiave pubblica. Così facendo, si da la possibilità sia di referenziare l'assembly con la corretta chiave pubblica (la stessa che verrà utilizzata firmando l'assembly regolarmente), sia di registrare lo stesso nella GAC.
Unica accortezza, in questo passaggio, è usare lo switch -Vr del tool SN.exe sull'assembly "parzialmente firmato" usando la sintassi:
SN.exe -Vr NomeAssembly.dll
In questo modo, il CLR salterà il controllo dell'Hash dell'assembly "parzialmente firmato". Controllo che fallirà in quanto l'assembly non è "completamente" firmato.
In questo modo si può procedere con lo sviluppo in tutta tranquillità, salvo poi, prima di andare in produzione, firmare gli assembly regolarmente e riabilitare il check dell'hash sulle macchine in cui era stato disabilitato usando lo switch -Vu.
Qualche riferimento su SN, Dalayed Signing etc. nei seguenti link:
http://msdn.microsoft.com/msdnmag/issues/06/07/CLRInsideOut/
http://msdn.microsoft.com/msdnmag/issues/01/03/buildapps2/
http://msdn2.microsoft.com/en-us/library/xc31ft41(VS.71).aspx
http://msdn2.microsoft.com/en-us/library/t07a3dye(VS.71).aspx