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

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?

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.

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'.

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

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.

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.

debe firmar el ensamblaje con una clave. Vaya a las propiedades del proyecto en la pestaña de firma:

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ó.

Eliminar el archivo DLL (donde se produjo el error) y reconstruir la solución solucionó mi problema. Gracias

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.

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

Compilación -> Reconstruir solución

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

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

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

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 ...

¿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 .

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.

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.

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

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.

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ó.

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ó.

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 ...

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.

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ó.

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.

Pruebe con update-package -reinstall -ignoredependencies

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í!