c# visual-studio .net-4.0

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



visual-studio .net-4.0 (26)

¿Está su asamblea debidamente firmada?

Para verificar esto, presione Alt + Intro en su proyecto (o haga clic derecho, luego Propiedades). Ir a "Firma". Verifique que la casilla de verificación "Firmar el ensamblaje" esté marcada y que el archivo de clave de nombre seguro esté seleccionado y que "Solo signo de retardo" no esté marcado .

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

Agregando mi solución para este problema para cualquier persona que pueda ayudar.

Tuve una solución ClickOnce lanzando este error. La aplicación hacía referencia a una carpeta "Libs" común y contenía una referencia de proyecto a un Foo.dll . Si bien ninguno de los proyectos en la solución hizo referencia a la copia estática de Foo.dll en la carpeta "Libs", algunas de las referencias en esa carpeta lo hicieron (es decir, mi solución tenía referencias a Libs/Bar.dll que hacía referencia a Foo.dll .) Debido a que la aplicación de CO eliminó todas las dependencias de Libs así como sus dependencias, ambas copias entraron en el proyecto. Esto generaba el error anterior.

Libs/Foo.dll el problema moviendo mi versión estática Libs/Foo.dll a 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ó.

Ahora aquí hay un enfoque diferente al problema:

  • Haga clic derecho en el proyecto y seleccione la opción ''Descargar proyecto''. Notarás que tu proyecto no estará 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" / > ).

  • Cambia eso para que quede como sigue:

.

<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 los cambios, haga clic con el botón derecho en el proyecto no disponible nuevamente y haga clic en la opción "Recargar proyecto", luego genere.

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

Construir -> Reconstruir Solución

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

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

Descargando y recargando el problema, el proyecto lo resolvió por mí.

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 (Automático) desde Incluir y finalmente funcionó.

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

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

Lo siguiente funciona como una solución cruda si no está utilizando ClickOnce (omitirá toda la información de dependencia del archivo .manifest ):

  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 archivo .targets al que se hace referencia (en mi caso, el archivo se resolvió en C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/MSBuild/Microsoft/VisualStudio/v15.0/OfficeTools/Microsoft.VisualStudio.Tools.Office.targets y yo hicimos una copia de Microsoft.VisualStudio.Tools.Office_FIX.targets en la misma carpeta; no verifiqué si funciona desde otra carpeta).

  4. Busque el elemento GenerateApplicationManifest y cambie su atributo Dependencies="@(DependenciesForGam)" a Dependencies="" .

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

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

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

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

Había demasiados proyectos en mi solución para realizar y actualizar individualmente, así que lo arreglé:

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

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

Ir a la página de propiedades del proyecto. Luego vaya a ''Publicar'' y luego ''Archivos de aplicación''. Las dlls mencionadas en el error se marcarán allí como requisito previo. Cambiarlos a ''Incluir''

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

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 clave y la información de la versión del nombre del ensamblaje en los archivos .csproj (no importaba de todos modos), y luego hacer una compilación limpia.

Los cambios entre las diferentes versiones de ensamblaje fueron compatibles con las partes de la solución que se refieren a ellos. Si este no es el caso con usted, es posible que tenga que 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 a un proyecto en su solución.
  2. Una nueva versión de ese paquete se implementa en la fuente del paquete.
  3. Se 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 conjuntos de ese paquete. Si uno de ellos hace referencia al otro y es una aplicación ClickOnce, verá este problema.

Para solucionar este problema, ejecute el comando update-package [package name] en la Consola de Nuget Package Manager para que todo esté a la altura de un campo de juego nivelado, en cuyo punto el problema desaparece.

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

Necesitas firmar la asamblea con una llave. Ir a las propiedades del proyecto en la pestaña de firma:

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 de NuGet asociados con mis propios ensamblajes.
Mi solución fue usar el administrador de paquetes de NuGet en la Solución, a diferencia de los proyectos individuales. Esto permite una opción de "consolidación", donde puede actualizar sus paquetes NuGet en tantos proyectos como desee, de modo que todos hagan referencia a la misma versión del ensamblaje. Cuando hice las consolidaciones, la falla de construcción desapareció.

Si ha cambiado su versión de ensamblaje o 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 ''Rebuild All'' (o la eliminación de sus ''bin y'' obj ''carpetas como se mencionó en un comentario anterior) debería solucionar este caso.

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

  • Tenga múltiples proyectos en su 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, utilizó Intellisense / ReSharper para traer 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 provisto por el paquete de NuGet y ese método se usa en el Proyecto A)
  • actualizó el paquete NuGet a través de NuGet Package Manager (o CLI).

... puede tener versiones separadas de la DLL de los paquetes de NuGet en las Referencias de sus proyectos, ya que la referencia creada por Intellisense / ReSharper será una referencia "normal", y no una referencia de NuGet como se esperaba, por lo que el proceso de actualización de NuGet no será válido. 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 de NuGet en todos los proyectos tengan la misma versión. (como se explica en esta respuesta )

Consejo de vida Pro:

Este problema puede surgir siempre que ReSharper / Intellisense sugiera agregar una referencia a su proyecto. Puede ser mucho más complejo que el ejemplo anterior, con múltiples proyectos y dependencias entrelazados que hacen que sea difícil rastrearlos. Si la referencia sugerida por ReSharper / Intellisense proviene de un paquete de NuGet, use NuGet para instalarlo.

Si no coinciden las dependencias de una dependencia, vaya al administrador de paquetes de NuGet en el nivel de la solución y verifique las pestañas Actualizar y Consolidar, armonice todo.

Si su proyecto principal utiliza algunos proyectos de biblioteca y tiene referencias a ellos, puede causar este problema si su proyecto hace referencia a un archivo dll de ensamblaje al proyecto de biblioteca cuando cambia algo en su proyecto de biblioteca (por ejemplo, renombrar una clase).

Puede verificar todas las referencias a su proyecto principal por vista en la ventana del Examinador de objetos (menú Ver-> Examinador 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.

También me topé con un tipo de problema, todo lo que tenía que hacer era eliminar el .dll (que se puede encontrar en la referencia) que causa el error y agregarlo nuevamente .

Funciona de maravilla.

Tengo el error de compilación similar. Una vez que agrego el proyecto dependiente del archivo dll a la solución, problema resuelto.

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

Normalmente me sale un error diferente en estos casos.

Mi solución fue eliminar el ensamblaje con nombre en cualquier lugar al que se hizo referencia y agregarlo nuevamente. 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 ...

Ver esta answer

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 están dando problemas tengan su estado de publicación marcado como "Incluir" en lugar de "Requisito previo".