¿Por qué obtengo 'Assembly' * .dll 'debe tener una firma fuerte para que se marque como un requisito previo'?


266

Estoy tratando de compilar mi complemento de Excel usando C # 4.0, y comencé a tener este problema al construir mi proyecto en Visual Studio. Es importante decirte que no he tenido este problema antes. ¿Qué podría causar que esto suceda?


72
Como un intento rápido, borre las carpetas biny objde su proyecto y vuelva a compilar el proyecto. A veces esto funciona.
Jason Evans

¿Estás firmando la asamblea?
Felice Pollano

3
@ Jason, la limpieza del proyecto y la reconstrucción funcionaron para mí. Acababa de firmar los ensamblajes y el proyecto se construiría, pero no se publicaría.
Kratz

1
@Kratz - Me alegro de que este consejo te haya funcionado :) ¡Es como arreglar tu computadora reiniciándola!
Jason Evans

Esto me sucedió cuando el administrador de configuración restableció la configuración de compilación en varios de mis proyectos (es decir, no estaban configurados para compilar en "Reconstruir todo"), después de versionar esos proyectos y reconstruir el error.
alan

Respuestas:


239

Mi conjetura es que no estás trabajando con ensamblajes fuertemente nombrados. He tenido este error cuando dos proyectos hacen referencia a versiones ligeramente diferentes del mismo ensamblaje y un proyecto más dependiente hace referencia a estos proyectos. La resolución en mi caso fue eliminar la información de la clave y la versión del nombre del ensamblado en los archivos .csproj (no importaba de todos modos), y luego hacer una compilación limpia.

Los cambios entre las diferentes versiones de ensamblaje eran compatibles con las partes de la solución que se referían a ellos. Si este no es su caso, es posible que deba trabajar un poco más para resolver el problema.

NuGet

Con NuGet es fácil entrar en esta situación si:

  1. Instala un paquete en un proyecto en su solución.
  2. Una nueva versión de ese paquete se implementa en el origen del paquete.
  3. Lo instala en otro proyecto en la misma solución.

Esto da como resultado dos proyectos en su solución que hacen referencia a diferentes versiones de los ensamblados de ese paquete. Si uno de ellos hace referencia al otro y es una aplicación ClickOnce, verá este problema.

Para solucionar esto, emita el update-package [package name]comando en la Consola del Administrador de paquetes de Nuget para llevar todo a un nivel de igualdad de condiciones, momento en el cual el problema desaparece.

Debe administrar los paquetes NuGet a nivel de solución en lugar de a nivel de proyecto a menos que haya una razón convincente para no hacerlo. La gestión de paquetes a nivel de solución evita el potencial de múltiples versiones de dependencias. Cuando utilice la IU de administración, si la pestaña Consolidado muestra que 1 o más paquetes tienen varias versiones, considere consolidarlos en uno.


77
Aquí hay más información: social.msdn.microsoft.com/Forums/en/csharplanguage/thread/… . Además, limpiar bin y obj y (si está bajo su control) establecer la versión del ensamblaje en el mismo valor (por ejemplo, dejar el número de compilación cero) ayuda.
Kit

3
He agregado un poco al final de su respuesta para reflejar mi propia experiencia hoy con NuGet y este mismo error. Espero que ayude a alguien en algún momento (¡posiblemente incluso a mí mismo en unos meses!).
Neil Barnwell

2
Este error sigue apareciendo y eliminando el nombre del ensamblado del archivo .csproj, luego la limpieza lo ha solucionado constantemente. ¡Gracias!
ScubaSteve

1
Es posible que desee ver esta respuesta si la respuesta anterior no funcionó y cree que agregó la referencia NuGet a uno de sus proyectos utilizando Intellisense / ReSharper.
David Murdoch

La solución contiene 4 proyectos. Un proyecto B es la biblioteca de clases. El dll de B estaba siendo referenciado en el resto de tres. Los otros dos de proyecto ( C y D ) ejecutable están siendo referencia en A . Entonces construí A y tuve el mismo problema. La solución fue reconstruir el resto de dos proyectos primero. Y luego reconstruir el proyecto Un problema resuelto.
Vikram Singh Saini

268

Cuando tuve este problema, lo solucioné desactivando la opción "Habilitar configuración de seguridad ClickOnce".

Menú: Proyecto | Propiedades 'Nombre del proyecto' ... | Pestaña de seguridad | Casilla de verificación 'Activar configuración de seguridad de ClickOnce'.


2
No funcionó para mí en VS2012 (la casilla de verificación se vuelve a marcar automáticamente durante la publicación). En su lugar, utilicé esta respuesta, ya que la DLL solo era necesaria para el proceso de compilación. stackoverflow.com/a/8123074/17713
Matthias Meid

3
Al usar ClickOnce, esta casilla de verificación se selecciona automáticamente cada vez que la aplicación se publica con el asistente de publicación. Consulte msdn.microsoft.com/en-us/library/1sfbfyk0.aspx para obtener más información.
David Murdoch

8
Tengo MSVS 2015 y no veo la pestaña de seguridad en las propiedades del proyecto
zeta

70

Mira esta respuesta .

Vaya a la página de publicación y haga clic en "Archivos de aplicación". A partir de ahí, debería ver una lista de sus DLL. Asegúrese de que los que le causan problemas tengan su estado de publicación marcado como "Incluir" en lugar de "Requisito previo".


2
El proyecto addin de exel no tiene el botón Archivos de aplicación. stackoverflow.com/questions/6378801/…
Sergey Kucher

@SergeyKucher: No lo sabía. Gracias por la actualización. Como su pregunta no es precisa, es para un complemento de Excel, creo que mi respuesta sigue siendo válida aquí (recibí el mismo mensaje de error en un proyecto winforms y lo resolví de esta manera).
Otiel

Tengo un proyecto winforms que funcionó bien hasta que utilicé el asistente de publicación, después de lo cual obtuve los errores del OP. Cambiar el estado de publicación solucionó el problema. Gracias
Kristian

77
En mi caso, este problema se resolvió cambiando el estado de publicación de INCLUDE (automático) a INCLUDE. De todos modos, su respuesta ayudó a no impulsar los valores mostrados. Muchas gracias
Julio Nobre

22

He tenido este problema Sucedió porque tenía muchos proyectos apuntando al mismo ensamblaje pero de diferentes versiones. Lo resuelvo seleccionando la misma versión para todos los proyectos en mi solución.


13

Si ha cambiado su versión de ensamblaje o ha copiado una versión diferente de la biblioteca administrada indicada en el error, también puede haber compilado previamente archivos que hacen referencia a la versión incorrecta. Un 'Reconstruir todo' (o eliminar las carpetas 'bin y' obj 'como se mencionó en un comentario anterior) debería solucionar este caso.


1
O simplemente 'Solución limpia'
cortar el

Un 'Reconstruir todo' realiza primero una limpieza, y es equivalente a 'limpiar' y luego 'construir'. Sin embargo, es bueno tener en cuenta que, a veces, cuando los archivos se han copiado manualmente o con diferentes marcas de tiempo, la funcionalidad 'limpiar' / 'reconstruir' no soluciona el problema y es necesario eliminar manualmente las carpetas 'bin' y 'obj'.
Sogger 01 de

Para este problema relacionado con Excel, eliminar las carpetas bin / obj funcionó para mí, los otros enfoques no lo hicieron.
William Melani

6

debe firmar el ensamblaje con una clave. Vaya a las propiedades del proyecto en la pestaña de firma: ingrese la descripción de la imagen aquí


6

Agregar mi solución para este problema a cualquiera que pueda ayudar.

Tuve una solución ClickOnce arrojando este error. La aplicación hacía referencia a una carpeta común "Libs" y contenía una referencia de proyecto a a Foo.dll. Si bien ninguno de los proyectos en la solución hacía referencia a la copia estática de la Foo.dllcarpeta "Libs", algunas de las referencias en esa carpeta sí (es decir: mi solución tenía referencias a las Libs\Bar.dllque se hacía referencia Foo.dll). Ya que la aplicación CO eliminó todas las dependencias de LibsAdemás de sus dependencias, ambas copias iban al proyecto. Esto estaba generando el error anterior.

He arreglado el problema moviendo mi Libs\Foo.dllversión estática en una subcarpeta, Libs\Fix\Foo.dll. Este cambio hizo que la aplicación ClickOnce usara solo la versión del proyecto de la DLL y el error desapareció.



6

Si probó todas las otras respuestas en esta pregunta y usted:

  • Ten múltiples proyectos en tu solución
  • Tenga un proyecto (Proyecto A) que haga referencia a otro proyecto (Proyecto B), cuyo proyecto haga referencia a un paquete NuGet.
  • En el Proyecto A, usó Intellisense / ReSharper para incorporar la referencia al paquete NuGet al que se hace referencia en el Proyecto B (esto puede suceder cuando un método en el Proyecto B devuelve un tipo proporcionado por el paquete NuGet y ese método se usa en el Proyecto A)
  • actualizado el paquete NuGet a través del Administrador de paquetes NuGet (o CLI).

... puede tener versiones separadas de la DLL de paquetes NuGet en las referencias de sus proyectos, ya que la referencia creada por Intellisense / ReSharper será una referencia "normal", y no una referencia NuGet como se esperaba, por lo que el proceso de actualización NuGet ganó ' t encontrarlo o actualizarlo!

Para solucionar esto, elimine la referencia en el Proyecto A, luego use NuGet para instalarlo y asegúrese de que los paquetes NuGet en todos los proyectos tengan la misma versión. (como se explica en esta respuesta )


Consejo de Life Pro:

Este problema puede surgir siempre que ReSharper / Intellisense sugiera agregar una referencia a su proyecto. Puede ser mucho más complicado que el ejemplo anterior, con múltiples proyectos y dependencias entrelazados que dificultan el seguimiento. Si la referencia sugerida por ReSharper / Intellisense es en realidad de un paquete NuGet, use NuGet para instalarlo.


Sí, evite usar Resharper para agregar referencias. Resharper tomará el dll de referencia de la carpeta de depuración (o liberación si está en modo de liberación). Eso causará muchos problemas, especialmente en grandes proyectos.
cepriego el

5

Cuando esto me sucedió con WindowsAPICodePack después de actualizarlo, simplemente reconstruí la solución.

Compilación -> Reconstruir solución


4

Había demasiados proyectos en mi solución para realizar y actualizar individualmente, así que arreglé esto de la siguiente manera:

  • Haga clic derecho en mi solución y seleccione 'Administrar paquetes NuGet para la solución ...'
  • Ir a la pestaña Actualizaciones
  • Encontrar el paquete afectado y seleccionar Actualizar
  • Hizo clic en Aceptar y esto actualizó todas las instancias del paquete

4

Descargar y volver a cargar el proyecto problemático lo resolvió por mí.


4

Fui a publicar , archivos de aplicación, encontré que el dll arrojando el error lo cambió a 'Incluir' desde 'Incluir (Auto)'. Ahora puedo publicar.


4

Encontré este problema después de migrar un complemento de Excel desde packages.config a PackageReference. Parece estar relacionado con este problema .

Lo siguiente funciona como una solución alternativa si no está usando ClickOnce (omitirá toda la información de dependencia del .manifestarchivo):

  1. Descargar proyecto, editar .csproj
  2. Encuentra la sección que se ve así:

    <!-- Include additional build rules for an Office application add-in. -->
    <Import Project="$(VSToolsPath)\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" Condition="'$(VSToolsPath)' != ''" />
  3. Edite una copia renombrada del .targetsarchivo al que se hace referencia (en mi caso, el archivo se resolvió C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targetse hice una copia Microsoft.VisualStudio.Tools.Office_FIX.targetsen la misma carpeta; no verifiqué si funciona desde una carpeta diferente).

  4. Encuentre el GenerateApplicationManifestelemento y cambie su atributo Dependencies="@(DependenciesForGam)"a Dependencies="".

  5. Cambie la sección que se encuentra en 2. para hacer referencia a su .targetsarchivo editado .

Esto tendrá que repetirse cada vez que .targetsse actualice la versión del archivo enviado con VS (o no recibirá las actualizaciones), pero espero que se solucione pronto ...


2
Para agregar a esto, una forma un poco más suave de solucionar el problema es copiar toda la sección <Target Name = "VisualStudioForApplicationsBuild"> del archivo ubicado en el punto 3 (es decir: solo encuentre el archivo, no lo copie y cambie el nombre) , al archivo de proyecto de su propio proyecto. **, y realice el mismo cambio que se describe en el punto 4. Esto anulará el comportamiento solo para su proyecto y no afectará nada más en su máquina. Si hay cambios en el archivo original en una futura actualización de VS, es posible que aún deba repetir el proceso.
Adam

3

¿Su ensamblaje está debidamente firmado?

Para verificar esto, presione Alt + Enter en su proyecto (o haga clic derecho, luego Propiedades). Vaya a "Firma". Verifique que la casilla de verificación "Firmar el ensamblado" esté marcada y que el archivo de clave de nombre seguro esté seleccionado y que "Retrasar solo firmar" esté desmarcado .


No he firmado el * .dll, pero no había ningún problema antes (no tenía el error de compilación antes). El dll al que se hace referencia en uno de los proyectos referenciados del publicado, encontré una solución fea para hacer referencia al dll directamente desde el proyecto publicado, ¿podría decirme por qué funciona ahora? ¿O cómo podría resolver el problema de otra manera? Gracias
Sergey Kucher

1
@ user520535: bueno, si no ha firmado la biblioteca antes, debería hacerlo. No es la única forma en que esta biblioteca puede ser utilizada por ensamblados firmados (un ensamblado firmado no puede llamar a uno no firmado), pero trabajar con ensamblajes no firmados también es muy complicado cuando se trata de complementos / agregar -En s. Ahora, ¿por qué comenzó a causar problemas ahora y no antes? No tengo idea.
Arseni Mourzenko

@ user520535: si ayudó, eres libre de aceptar o votar la respuesta.
Arseni Mourzenko

3

Ahora, aquí hay un enfoque diferente del problema:

  • Haga clic derecho en el proyecto y seleccione la opción 'Descargar proyecto'. Notará que su proyecto no está disponible.

  • Haga clic derecho en el proyecto no disponible y seleccione la opción 'Editar'.

  • Desplácese hacia abajo hasta la etiqueta '<ItemGroup>' que contiene todas las etiquetas de recursos.

  • Ahora vaya a la referencia que se ha mostrado en la lista de errores, notará que usa una sola etiqueta (es decir < Reference Include="assemble_name_here, Version=0.0.0.0, Culture=neutral" / >).

  • Cambie eso para que se vea de la siguiente manera:

.

<Reference Include="assemble_name_here, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL" >
    < Private > True < / Private >
    < HintPath > path_here\assemble_name_here.dll < / HintPath >
< / Reference >
  • Guarde sus cambios, haga clic derecho en el proyecto no disponible nuevamente y haga clic en la opción 'Recargar proyecto', luego compile.

3

Esto se produce cuando cambia la versión del .dll al que se hace referencia. Debe eliminar todos los elementos o el .dll en la carpeta de compilación de destino.


2

Obtuve el error similar del compilador. Una vez que agrego el proyecto dependiente del archivo dll a la solución, el problema se resolvió.


2

Si su proyecto principal usa algunos proyectos de biblioteca y tiene referencia a ellos, puede causar este problema si su proyecto hace referencia a un archivo dll de ensamblaje en lugar de proyecto de biblioteca cuando cambia algo en su proyecto de biblioteca (por ejemplo: cambiar el nombre de una clase).

Puede verificar todas las referencias a su proyecto principal mediante la vista en la ventana del Explorador de objetos (menú Ver-> Explorador de objetos). Una referencia a un archivo dll siempre tiene un número de versión. Ej: TestLib [1.0.0.0]

Solución: elimine la referencia actual de su proyecto principal al proyecto de biblioteca y agregue nuevamente la referencia a ese proyecto de biblioteca.


1

Después de probar la mayoría de las soluciones aquí, finalmente agregué una referencia al proyecto desde el proyecto de clic una vez, esto lo cambió a Incluir (Auto) desde Incluir y finalmente funcionó.


1

Lo que me ayudó fue que fui a Package Manager Solution y miré el paquete instalado que estaba causando el problema. Vi que varios proyectos hacían referencia al mismo paquete pero a versiones diferentes. Los alineé según mis necesidades y funcionó.


0

Tenía esto en una solución con 6 proyectos. Uno de mis proyectos se refería al ensamblado nombrado como referencia de archivo. Los demás apuntaban a la referencia del proyecto.

Por lo general, obtengo un error diferente en estos casos.

Mi solución fue eliminar el ensamblado con nombre en cualquier lugar al que se hiciera referencia y volver a agregarlo. Una vez que trabajé en el proyecto, este problema desapareció. Antes de hacer esto, intenté limpiar la solución y asegurarme de que ninguno de los proyectos estuviera firmado.

Espero que ayude a alguien ...


0

Si no coinciden las dependencias de dependencias, vaya al administrador de paquetes NuGet en el nivel de solución y verifique las pestañas Actualizar y Consolidar, armonícelo todo.


0

Recientemente me topé con este problema. En mi caso, tengo paquetes NuGet en diferentes ensamblajes. Lo que tenía eran diferentes versiones de los mismos paquetes NuGet asociados con mis propios ensamblajes.
Mi solución fue usar el administrador de paquetes NuGet sobre la Solución, en lugar de los proyectos individuales. Esto habilita una opción de "consolidación", donde puede actualizar sus paquetes NuGet en tantos proyectos como desee, por lo que todos hacen referencia a la misma versión del ensamblaje. Cuando hice las consolidaciones, la falla de compilación desapareció.


0

También me encuentro con un tipo de problema, todo lo que tengo que hacer es eliminar el .dll (que se puede encontrar en la referencia) que está causando el error y agregarlo nuevamente .

Funciona de maravilla.



0

Simplemente vaya a Publicar -> Archivo de aplicación -> ¡Y cambie el estado de publicación de dll afectado de prerrequisito para incluir! ¡Esto funcionó para mí!

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.