posizione del file .snk e gestione di esso

Question

Attualmente sto configurando le mie librerie .net da firmare con una chiave fortemente tipizzata. Sto usando il file .snk per firmare la mia dll in base alla soluzione. Quindi, per ogni soluzione, ha il proprio file .snk. È questa pratica corretta? Ad esempio, ho una libreria di classi che restituisce diverse dll da ciascuno dei progetti all'interno della soluzione, ciascuna firmata con la chiave .snk.

La mia domanda circonda la memorizzazione della chiave nel controllo sorgente. Come ramo il mio codice per ogni versione. Se la chiave:

A. trovarsi fuori dei rami e non essere ramificato - assicurandone la stessa chiave per ogni ramo B. esiste all'interno del ramo ma essere la stessa per ciascun ramo C. Esiste all'interno del ramo e cambiamento per ogni ramo D. Altro (specificare)

Suggerimenti per favore?

È inoltre consigliabile eseguire la firma delle DLL inserendo quanto segue nel file SolutionInfo o esiste un'alternativa?

[assembly: AssemblyKeyFile("<<absolute path>>\\MyKey.snk")] 

Answer 1

A seconda della specifica implementazione, è in genere le migliori pratiche per mantenere il file chiave .snk nel ramo su cui stai lavorando.

Il caso d'uso è: stiamo cambiando la chiave di firma dell'assembly tra v1.0 e v2.0. Si vorrebbe comunque essere in grado di mantenere il codice corrente nel bagagliaio, mentre si sta sviluppando contro la chiave corretta nel proprio (i) ramo (i).

In secondo luogo, (e questo è solo una best practice, non è necessario a seconda della situazione - ad esempio quanto bene ti fidi gli altri sviluppatori) il file snk si mantiene in controllo del codice sorgente dovrebbe contenere solo una chiave pubblica, e la la soluzione deve essere configurata per ritardare solo il segno.

Ciò impedisce la diffusione della chiave privata, che deve essere archiviata protetta sul server di build (molto probabilmente nel gestore di chiavi di Windows) e utilizzata durante le build di "rilascio" per firmare completamente gli assembly. Se non si dispone di un server di build, è consigliabile disporre di 1 o 2 persone a cui è affidata la chiave privata, a quel punto possono firmare gli assembly con sn.exe dopo la generazione. Un semplice script di shell o un file batch può automatizzare questo processo.

Infine, e solo se si sceglie di ritardare il segno, è necessario aggiungere una voce all'elenco di verifica dell'assembly .NET (sn.exe -Vr *,<publicKeyToken>) su tutte le workstation dello sviluppatore che eseguono/eseguono il debug degli assembly con firma del ritardo. A seconda dell'obiettivo della piattaforma, è necessario eseguirlo nelle versioni a 32 e 64 bit del prompt dei comandi VS.

Spero che questo aiuti.

Answer 2

Esistono due strategie di base. Il primo è adatto per aziende molto grandi che hanno bisogno di temere che qualcun altro sostituisca i propri assembly per scopi dannosi. Personalità come Microsoft, Adobe o Oracle. Nessuno, a parte un piccolo gruppo di ingegneri esperti, ha accesso alla chiave, il codice è sviluppato e testato dalla firma del ritardo.

L'altro è per tutti gli altri, basta firmare l'assembly per farlo entrare in GAC o perché lo spedisci a un secondo partito che potrebbe desidera inserirlo nel GAC. La chiave effettiva che usi non ha importanza e non devi metterla in un grande caveau. Basta usare Progetto + Proprietà, scheda Firma. Genera una chiave e controllala insieme al progetto.