Agregué un ensamblado con un nombre débil a mi proyecto de Visual Studio 2005 (que tiene un nombre fuerte). Ahora recibo el error:

"El ensamblado al que se hace referencia 'xxxxxxxx' no tiene un nombre seguro"

¿Debo firmar este ensamblaje de terceros?

Para evitar este error, podrías:

• Cargue el ensamblaje dinámicamente, o
• Firmar la asamblea de terceros.

Encontrará instrucciones sobre cómo firmar ensamblados de terceros en .NET-fu: Firmar un ensamblado sin firmar (sin firma de retraso) .

Firma de Asambleas de terceros

El principio básico para firmar una fiesta de sed es

1. Desmontar el ensamblaje utilizando ildasm.exey guardar el lenguaje intermedio (IL):

   ildasm /all /out=thirdPartyLib.il thirdPartyLib.dll 

2. Reconstruir y firmar el ensamblaje:

   ilasm /dll /key=myKey.snk thirdPartyLib.il

Arreglando referencias adicionales

Los pasos anteriores funcionan bien a menos que su ensamblado de terceros ( A.dll ) haga referencia a otra biblioteca ( B.dll ) que también tiene que estar firmada. Puede desmontar, reconstruir y firmar A.dll y B.dll utilizando los comandos anteriores, pero en el tiempo de ejecución, la carga de B.dll fallará porque A.dll se creó originalmente con una referencia a la versión sin firmar de B.dll .

La solución a este problema es parchear el archivo IL generado en el paso 1 anterior. Deberá agregar el token de clave pública de B.dll a la referencia. Obtienes este token llamando

sn -Tp B.dll 

que te dará el siguiente resultado:

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.33440
Copyright (c) Microsoft Corporation.  All rights reserved.

Public key (hash algorithm: sha1):
002400000480000094000000060200000024000052534131000400000100010093d86f6656eed3
b62780466e6ba30fd15d69a3918e4bbd75d3e9ca8baa5641955c86251ce1e5a83857c7f49288eb
4a0093b20aa9c7faae5184770108d9515905ddd82222514921fa81fff2ea565ae0e98cf66d3758
cb8b22c8efd729821518a76427b7ca1c979caa2d78404da3d44592badc194d05bfdd29b9b8120c
78effe92

Public key token is a8a7ed7203d87bc9

La última línea contiene el token de clave pública. Luego debe buscar en el IL de A.dll la referencia a B.dll y agregar el token de la siguiente manera:

.assembly extern /*23000003*/ MyAssemblyName
{
  .publickeytoken = (A8 A7 ED 72 03 D8 7B C9 )                         
  .ver 10:0:0:0
}

Expanda el archivo de proyecto que está utilizando el proyecto que no "tiene una clave de nombre .snksegura " y busque el archivo (.StrongNameKey).

Busque este archivo en el Explorador de Windows (solo para saber dónde está).

De vuelta en Visual Studio en el proyecto que no "tiene una clave de nombre segura", haga

• Haga clic derecho en el archivo del proyecto
• Seleccionar propiedades
• Seleccione "pestaña Firma" (a la izquierda)
• Haga clic en la casilla de verificación "Firmar el ensamblado"
• Luego <Browse>al .snkarchivo que encontraste anteriormente

Eso debería hacer el truco. Esto resolvió un problema para mí para un proyecto usando un formulario dentro de otro proyecto en la misma solución.

Espero que ayude.

Estaba buscando una solución para el mismo problema y la opción de desmarcar "Firmar el ensamblaje" funciona para mí:

(Como puede observar, la captura de pantalla proviene de VS2010, pero con suerte ayudará a alguien)

He escrito una herramienta para ensamblar signos de nombre automático, incluidos aquellos para los que no tiene el código fuente o proyectos que han sido abandonados. Utiliza muchas de las técnicas descritas en las respuestas de una manera simple sin ninguno de los defectos o inconvenientes de las herramientas existentes o las instrucciones con fecha.

http://brutaldev.com/post/2013/10/18/NET-Assembly-Strong-Name-Signer

Espero que esto ayude a cualquiera que necesite firmar un ensamblaje de terceros sin tener que saltar a través de los aros para llegar allí.

Puede usar ensamblajes sin firmar si su ensamblaje también está sin firmar.

Firmar la asamblea de terceros funcionó para mí:

http://www.codeproject.com/Tips/341645/Referenced-assembly-does-not-have-a-strong-name

EDITAR : he aprendido que es útil publicar pasos en caso de que el artículo vinculado ya no sea válido. Todo el crédito va a Hiren Khirsaria :

1. Ejecute el símbolo del sistema de Visual Studio y vaya al directorio donde se encuentra su DLL.

   For Example my DLL is located in D:/hiren/Test.dll

2. Ahora cree el archivo IL usando el comando a continuación.

   D:/hiren> ildasm /all /out=Test.il Test.dll (este comando genera la biblioteca de códigos)

3. Genere una nueva clave para firmar su proyecto.

   D:/hiren> sn -k mykey.snk

4. Ahora firme su biblioteca usando el ilasmcomando.

   D:/hiren> ilasm /dll /key=mykey.snk Test.il

Cómo firmar un ensamblado de terceros sin firmar

1. Abra el símbolo del sistema del desarrollador para Visual Studio. Esta herramienta está disponible en sus programas de Windows y se puede encontrar utilizando la búsqueda predeterminada de Windows.
2. Asegúrese de que su solicitud tenga acceso a las siguientes herramientas ejecutándolas una vez: sn ildasmyilasm
3. Navegue a la carpeta donde se encuentra su Cool.Library.dll
4. sn –k Cool.Library.snk para crear un nuevo par de claves
5. ildasm Cool.Library.dll /out:Cool.Library.il desmontar la biblioteca
6. move Cool.Library.dll Cool.Library.unsigned.dll para mantener la biblioteca original como respaldo
7. ilasm Cool.Library.il /dll /resource=Cool.Library.res /key=Cool.Library.snk volver a montar la biblioteca con un nombre seguro
8. powershell -command "& {[System.Reflection.AssemblyName]::GetAssemblyName($args).FullName} Cool.Library.dll"para obtener el nombre completo de la asamblea. Necesitará este bit si tiene que hacer referencia a la DLL en archivos de configuración externos como web.config o app.config.

Tuve este problema para una aplicación que tenía un nombre fuerte y luego tuve que cambiarla para hacer referencia a un ensamblaje sin nombre, así que desmarqué 'Firmar el ensamblado' en la sección Firma de las propiedades del proyecto, pero aún se quejó. Pensé que tenía que ser un artefacto en algún lugar que causara el problema, ya que hice todo lo demás correctamente y fue solo eso. Encontré y eliminé la línea: [assembly: AssemblyKeyFile ("yourkeyfilename.snk")] de su archivo assemblyInfo.cs. Entonces no hay quejas después de eso.

Me encontraba con esto con un ServiceStack dll que había instalado con nuget. Resulta que había otro conjunto de dlls disponibles que estaban etiquetados como firmados. No será la respuesta para todos, pero es posible que solo necesite verificar una versión firmada existente de su ensamblaje.

Para mí, mi problema era que tenía dos de los mismos paquetes NuGet instalados con diferentes versiones.

Eliminar la marca de verificación "Firmar el ensamblaje" debajo de la pestaña "Firma" funciona como dijo @Michal Stefanow.

Agregar aquí es la forma más sencilla de firmar sus propios archivos y / o los archivos de otras personas. Solo necesita agregar esta línea debajo de la "Línea de comando del evento posterior a la compilación":

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\signtool.exe" sign /f "$(ProjectDir)\YourPfxFileNameHere.pfx" /p YourPfxFilePasswordHere /d "Your software title here" /du http://www.yourWebsiteHere.com /t http://timestamp.verisign.com/scripts/timstamp.dll /v "$(BaseOutputPath)$(TargetFileName)"

Puede firmar los archivos de otras personas o sus propios archivos y todos los que desee.

Antigua pregunta, pero me sorprende que nadie haya mencionado ilmerge todavía. ilmerge es de Microsoft, pero no se envía con VS o los SDK. Sin embargo, puedes descargarlo desde aquí . También hay un repositorio de github . También puede instalar desde nuget:

PM>Install-Package ilmerge

Usar:

ilmerge assembly.dll /keyfile:key.snk /out:assembly.dll /targetplatform:v4,C:\Windows\Microsoft.NET\Framework\v4.0.30319 /ndebug

Si es necesario, puede generar su propio archivo de claves utilizando sn (de VS):

sn -k key.snk

Situación: tenía el proyecto A, B, C, D en la solución X, Y

Proyecto A, B, C en X Proyecto A, C, D en Y

Necesito usar el proyecto C en el proyecto A, pero luego no lo uso. En bin Debug, el proyecto A tenía C.dll.

Si compilo la solución X, todo bien (en esta solución elimino la referencia A -> C.), pero en la solución Y obtengo este problema.

La solución es eliminar C.dll en el proyecto A bin Debug

Primero asegúrese de que todos los paquetes nuget estén en la misma versión en todos los proyectos de su solución. por ejemplo, no desea que un proyecto haga referencia a NLog 4.0.0.0 y otro proyecto haga referencia a NLog 4.1.0.0. Luego intente reinstalar paquetes nuget con

Update-Package -reinstall

Tuve 3 asambleas de terceros a las que hacía referencia mi asamblea A y solo 2 fueron incluidas en las referencias de mi asamblea B que también hacía referencia a A.

El comando de paquete de actualización agregó la referencia faltante al ensamblado de terceros y el error desapareció.