Come posso firmare fortemente una DLL esterna mantenendo i suoi metadati di assembly?

Question

Ho alcune librerie che uso nel mio progetto che non sono firmate. Poiché la mia applicazione è fortemente firmata, anche le librerie devono esserlo.

firmo queste librerie utilizzando:

"%PROGRAMFILES%\Microsoft SDKs\Windows\v7.1\Bin\ildasm.exe" /nobar /all /out=library.il library.dll 
"%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\ilasm.exe" /dll /key=MyKey.snk library.il 

Il problema è che tutti i metadati, come ad esempio i numeri di versione, perdersi nella DLL ormai firmato. Questo è un problema perché ora alcune dipendenze tra le librerie sono interrotte. Come posso conservare i numeri di versione senza ricorrere alla compilazione del codice sorgente di tali librerie?

UPDATE

In realtà è un particolare DLL che mostra questo problema e ho scoperto che è costruito utilizzando ILMerge. Forse questo sta causando il problema. Giusto per essere chiari: la DLL prodotta da ILMerge ha i metadati corretti, solo dopo averlo disassemblato e riassemblato, i metadati scompaiono.

UPDATE 2

ho aperto la DLL in Reflector e sembra che almeno il numero di versione è ancora lì. Stavo controllando sempre usando la finestra di dialogo delle proprietà dei file/dettagli in Windows Explorer. Quindi immagino che sia il manifest che manca invece.

Answer 1

Mi chiedo perché questo accada. Ho una discreta esperienza nella compilazione di round-trip usando ilmasm e ildasm anche su insiemi non firmati e firmati. Si può verificare che l'uscita dei metadati da ILAsm contiene ancora le informazioni sulla versione (in basso del campo di applicazione di montaggio):

.assembly ConsoleApplication1 
{ 
    //... 
    .hash algorithm 0x00008004 
    .ver 1:0:0:0 
} 

appena controllato ancora una volta, "funziona sulla mia macchina" (usando le esatte switch stessa riga di comando che avete fatto) .

Quali saranno effettivamente perso è la FileVersion attributo (quella che vedete in Esplora risorse quando si libra sopra l'assemblea. Il AssemblyVersion attributo è ancora presente e corretto. Potrebbe essere che stai confondendo il due? Solo il AssemblyVersion è importante per informazioni vincolanti. Vedi questo SO post per maggiori informazioni.

Spero potrebbe aiutare, altrimenti avresti bisogno di fornire più contesto.

Answer 2

Se avete il codice sorgente , quindi ricompila le librerie con nomi forti: il disassemblaggio e il rimontaggio di solito funzionano abbastanza bene, ma è ancora un hack.

Per mantenere le dipendenze tra le librerie funzionanti, è necessario aggiornare i riferimenti nel codice .il per utilizzare la chiave pubblica dell'assembly a cui fanno riferimento, altrimenti proveranno a fare riferimento a una versione non firmata dell'assembly, e quindi non riescono a caricarlo in fase di runtime.

È possibile farlo manualmente, ma diventa molto noioso dopo 2 o 3 assemblaggi. Una soluzione rapida per questo è signer, che si occupa di molte delle difficoltà che ti riguardano, e fa un ottimo lavoro - di solito è piuttosto veloce e pulito.

(Si noti che al momento è stato costruito su una vecchia versione .NET. Se si utilizzano gli assembly C# 4/.NET 4 è necessario scaricare l'origine, modificarla come destinazione.NET 4 e ricostruirlo per ottenere un signer.exe che gestirà correttamente gli assembly di .NET 4).