Wie kann ich eine externe DLL stark unter Beibehaltung ihrer Assemblymetadaten signieren?

Question

Ich habe ein paar Bibliotheken, die ich in meinem Projekt verwende, die nicht signiert sind. Da meine Anwendung stark signiert ist, müssen auch die Bibliotheken funktionieren.

Ich unterzeichne diese Bibliotheken mit:

"%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 

Das Problem ist, dass jede Metadaten wie Versionsnummern, in dem jetzt unterzeichneten DLL verloren gehen. Dies ist ein Problem, da jetzt einige Abhängigkeiten zwischen den Bibliotheken unterbrochen sind. Wie behalte ich die Versionsnummern, ohne den Quellcode dieser Bibliotheken tatsächlich zu kompilieren?

UPDATE

Es ist eigentlich eine bestimmte DLL, die dieses Problem zeigt, und ich habe, dass ILMerge mit integrierten herausgefunden wird. Vielleicht verursacht das das Problem. Nur um es klar zu stellen: Die DLL, die von ILMerge erzeugt wird, hat die richtigen Metadaten, erst nachdem sie zerlegt und neu zusammengesetzt wurden, verschwinden die Metadaten.

UPDATE 2

öffnete ich die DLL in Reflector und es scheint, dass die Versionsnummer immer noch da zumindest ist. Ich habe die Verwendung des Dateieigenschaften-Dialogfelds/Details im Windows Explorer ständig überprüft. So stelle ich fest, dass es das Manifest ist, das stattdessen fehlt.

Answer 1

Ich frage mich, warum das passiert. Ich habe recht gute Erfahrungen im Round-Trip-Compiling mit ilasm und ildasm auf nicht signierten und signierten Baugruppen. Können Sie die Metadaten Ausgabe von ILASM noch enthält die Versionsinformationen (Unterseite des Montage scope) überprüfen:

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

einfach wieder eingecheckt, es „funktioniert auf meinem Rechner“ (exakt die gleichen Kommandozeilen-Switches wie du) .

Was tatsächlich verloren gehen, ist die Fileversion Attribut (die Sie in Windows Explorer zu sehen, wenn sie über die Montage schwebt. Die Assembly Attribut ist noch vorhanden und korrekt. Könnte es sein, du bist verwirrend zwei? Nur die AssemblyVersion ist wichtig für die Bindung Informationen. sehen Sie diese für weitere Informationen SO post.

Hoffe, dass ich helfen konnte, sonst würden Sie mehr Kontext zur Verfügung stellen müssen.

Answer 2

Wenn Sie den Quellcode , dann kompilieren Sie einfach die Bibliotheken mit starken Namen neu - das Zerlegen und Zusammenbauen funktioniert normalerweise ziemlich gut, aber es ist immer noch ein Hack.

Um Abhängigkeiten zwischen den Bibliotheken aufrechtzuerhalten, müssen Sie die Verweise im .IL-Code aktualisieren, um den öffentlichen Schlüssel der Assembly zu verwenden, auf die sie verweisen, andernfalls versuchen sie eine nicht signierte Version der Assembly zu referenzieren Fehler beim Laden zur Laufzeit.

Sie können dies von Hand tun, aber es wird sehr mühsam nach 2 oder 3 Baugruppen. Eine schnelle Lösung dafür ist signer, die sich mit vielen der Schwierigkeiten beschäftigt, die mit Ihnen zu tun haben, und macht einen großartigen Job - es ist normalerweise ziemlich schnell und sauber.

(Beachten Sie, dass es zur Zeit gegen eine alte .NET-Version gebaut wurde. Wenn Sie C# 4/.NET 4-Assemblys verwenden, müssen Sie die Quelle herunterladen, ändern Sie sie zum Ziel.NET 4 und erstellen Sie es neu, um eine signer.exe zu erhalten, die .NET 4-Assemblys korrekt behandelt).