¿Cómo puedo firmar fuertemente una DLL externa mientras conserva sus metadatos de ensamblaje?

Question

Tengo algunas bibliotecas que utilizo en mi proyecto que no están firmadas. Debido a que mi aplicación está fuertemente firmada, las bibliotecas también deben estarlo.

firmo estas bibliotecas usando:

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

El problema es que los metadatos, tales como números de versión, se pierden en la DLL ahora firmado. Esto es un problema porque ahora algunas dependencias entre las bibliotecas están rotas. ¿Cómo retengo los números de versión sin recurrir a la compilación del código fuente de esas bibliotecas?

ACTUALIZACIÓN

En realidad es un archivo DLL en particular que muestra este problema y he descubierto que se construye utilizando ILMerge. Quizás esto está causando el problema. Para que quede claro: la DLL que produce ILMerge tiene los metadatos adecuados, solo después de desmontarla y volver a montarla, los metadatos desaparecen.

ACTUALIZACIÓN 2

me abrió la DLL en el reflector y parece que, al menos, el número de versión es todavía allí. Estaba comprobando usando el cuadro de diálogo de propiedades de archivo/detalles en el Explorador de Windows todo el tiempo. Entonces me imagino que es el manifiesto que falta en su lugar.

Answer 1

Me pregunto por qué sucede esto. Tengo una experiencia bastante buena en la compilación de ida y vuelta utilizando ilasm e ildasm en ensambles sin firmar y firmados. Se puede comprobar la salida de metadatos por ILASM todavía contiene la información de versión (parte inferior del marco de montaje):

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

Sólo comprueba de nuevo, que "funciona en mi máquina" (usando los interruptores exactas misma línea de comandos como lo hizo) .

lo que realmente se pierde es la FileVersion atributo (el que se ve en Windows Explorer cuando se cierne sobre el conjunto. El AssemblyVersion atributo es todavía está presente y correcta. Podría ser que estés confundiendo el dos? Sólo el AssemblyVersion es importante para la información de enlace. Ver este SO post para obtener más información.

esperanza que podría ayudar, de lo contrario se necesitaría para proporcionar más contexto.

Answer 2

Si tiene el código fuente , entonces simplemente recompile las bibliotecas con nombres fuertes: desarmar y volver a ensamblar generalmente funciona bastante bien, pero sigue siendo un truco.

Para mantener en funcionamiento las dependencias entre las bibliotecas, debe actualizar las referencias en el código .il para usar la clave pública del ensamblado al que hacen referencia, de lo contrario intentarán hacer referencia a una versión del ensamblaje sin firmar, y por lo tanto no puede cargarlo en tiempo de ejecución.

Puede hacerlo a mano, pero se vuelve muy tedioso después de 2 o 3 ensamblajes. Una solución rápida para esto es signer, que se ocupa de muchas de las dificultades involucradas para usted, y hace un gran trabajo; por lo general, es bastante rápido y limpio.

(Tenga en cuenta que en la actualidad se ha creado con una versión anterior de .NET. Si utiliza conjuntos C# 4/.NET 4, deberá descargar la fuente y cambiarla al destino.NET 4 y reconstruirlo para obtener un signer.exe que manejará correctamente los ensamblados .NET 4).