La definición del manifiesto del ensamblado ubicado no coincide con la referencia del ensamblado

https://stackoverflow.com/questions/215026

03-07-2019
|

Pregunta

Estoy intentando ejecutar algunas pruebas unitarias en una aplicación C# Windows Forms (Visual Studio 2005) y aparece el siguiente error:

System.IO.FileLoadException:No se pudo cargar el archivo o ensamblado 'Utilidad, Versión=1.2.0.200, Cultura=neutral, PublicKeyToken=764d581291d764f7' o una de sus dependencias.La definición del manifiesto del ensamblado ubicado no coincide con la referencia del ensamblado.(Excepción de HRESULT:0x80131040)**

en x.Foo.FooGO()

en x.Foo.Foo2 (String groupName_) en Foo.cs: línea 123

en x.Foo.UnitTests.FooTests.TestFoo() en FooTests.cs: línea 98**

System.IO.FileLoadException:No se pudo cargar el archivo o ensamblado 'Utilidad, Versión=1.2.0.203, Cultura=neutral, PublicKeyToken=764d581291d764f7' o una de sus dependencias.La definición del manifiesto del ensamblado ubicado no coincide con la referencia del ensamblado.(Excepción de HRESULT:0x80131040)

Miro en mis referencias y solo tengo una referencia a Utility version 1.2.0.203 (el otro es viejo).

¿Alguna sugerencia sobre cómo puedo descubrir qué intenta hacer referencia a esta versión anterior de este archivo DLL?

Además, creo que ni siquiera tengo este viejo ensamblaje en mi disco duro.¿Existe alguna herramienta para buscar este ensamblaje versionado antiguo?

Solución

El cargador de ensamblados .NET no puede encontrar 1.2.0.203, pero encontró un 1.2.0.200. Este ensamblado no coincide con lo solicitado y, por lo tanto, obtiene este error. En palabras simples, no puede encontrar el ensamblado al que se hizo referencia. Asegúrese de que pueda encontrar el ensamblaje correcto colocándolo en el GAC o en la ruta de la aplicación. Consulte también http://blogs.msdn.com/junfeng/archive /2004/03/25/95826.aspx .

Otros consejos

Puede hacer un par de cosas para solucionar este problema. Primero, use la búsqueda de archivos de Windows para buscar en su disco duro su ensamblado (.dll). Una vez que tenga una lista de resultados, haga Ver - & Gt; Elija Detalles ... y luego marque & Quot; Versión de archivo & Quot ;. Esto mostrará el número de versión en la lista de resultados, para que pueda ver de dónde podría provenir la versión anterior.

Además, como dijo Lars, verifique su GAC para ver qué versión aparece allí. Este artículo de Microsoft establece que los ensamblajes encontrados en el GAC no se copian localmente durante una compilación, por lo que es posible que deba eliminar la versión anterior antes de reconstruir todo. (Consulte mi respuesta a esta pregunta para obtener notas sobre cómo crear un archivo por lotes para hacer esto para ti)

Si aún no puede determinar de dónde proviene la versión anterior, puede usar la aplicación fuslogvw.exe que se incluye con Visual Studio para obtener más información sobre las fallas de enlace. Microsoft tiene información sobre esta herramienta aquí . Tenga en cuenta que deberá habilitar el registro configurando la HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog clave de registro en 1.

Acabo de encontrarme con este problema yo mismo, y descubrí que el problema era algo diferente de lo que los demás se han encontrado.

Tenía dos archivos DLL a los que hacía referencia mi proyecto principal: CompanyClasses.dll y CompanyControls.dll. Recibía un error de tiempo de ejecución que decía:

No se pudo cargar el archivo o ensamblaje 'CompanyClasses, Version = 1.4.1.0, Cultura = neutral, PublicKeyToken = 045746ba8544160c 'o Una de sus dependencias. El ubicado definición de manifiesto de la asamblea hace no coincide con la referencia de ensamblaje

El problema era que no tenía ningún archivo CompanyClasses.dll en mi sistema con un número de versión 1.4.1. Ninguno en el GAC, ninguno en las carpetas de la aplicación ... ninguno en ninguna parte. Busqué en todo mi disco duro. Todos los archivos CompanyClasses.dll que tenía eran 1.4.2.

El verdadero problema, descubrí, era que CompanyControls.dll hacía referencia a la versión 1.4.1 de CompanyClasses.dll. Acabo de recompilar CompanyControls.dll (después de hacer referencia a CompanyClasses.dll 1.4.2) y este error desapareció.

Lo siguiente redirige cualquier versión de ensamblaje a la versión 3.1.0.0. Tenemos un script que siempre actualizará esta referencia en App.config para que nunca tengamos que tratar este problema nuevamente.

A través de la reflexión, puede obtener el ensamblado publicKeyToken y generar este bloque desde el archivo .dll.

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <dependentAssembly>
    <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" />
  </dependentAssembly>
</assemblyBinding>

Tenga en cuenta que sin un atributo de espacio de nombres XML (xmlns) esto no funcionará.

Si está utilizando Visual Studio, intente " solución limpia " y luego reconstruya su proyecto.

Las otras respuestas no funcionarían para mí. Si no te importa la versión y solo quieres que tu aplicación se ejecute, haz clic derecho en la referencia y configura 'versión específica' en falso ... Esto funcionó para mí. ingrese la descripción de la imagen aquí

Acabo de encontrarme con este problema y el problema era que tenía una copia antigua del .dll en el directorio de depuración de mi aplicación. Es posible que también desee verificar allí (en lugar del GAC) para ver si lo ve.

Agregué un paquete NuGet, solo para darme cuenta de que una porción de recuadro negro de mi aplicación hacía referencia a una versión anterior de la biblioteca.

Eliminé el paquete y hice referencia al archivo DLL estático de la versión anterior, pero el archivo web.config nunca se actualizó desde:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

a lo que debería haber vuelto cuando desinstalé el paquete:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

En mi caso, este error ocurrió mientras ejecutaba una aplicación ASP.NET.La solución fue:

Borrar el obj y bin carpetas en la carpeta del proyecto

La limpieza no funcionó, la reconstrucción no funcionó, todas las referencias estaban bien, pero no estaba escribiendo una de las bibliotecas.Después de eliminar esos directorios, todo funcionó perfectamente.

En mi caso, era una versión anterior de la DLL en el directorio C: \ WINDOWS \ Microsoft.NET \ Framework \ ~ \ Temporary ASP.NET Files \. Puede eliminar o reemplazar la versión anterior, o puede eliminar y volver a agregar la referencia a la DLL en su proyecto. Básicamente, de cualquier manera creará un nuevo puntero a los archivos temporales de ASP.NET.

Voy a volar la mente de todos en este momento. . .

Elimine todas las referencias <assemblyBinding> de su archivo .config y luego ejecute este comando desde la consola de NuGet Package Manager:

Get-Project -All | Add-BindingRedirect

Para nosotros, el problema fue causado por algo más. El archivo de licencia para los componentes DevExpress incluía dos líneas, una para una versión anterior de los componentes que no estaba instalada en esta computadora en particular. Eliminar la versión anterior del archivo de licencia resolvió el problema.

La parte molesta es que el mensaje de error no indicó qué referencia estaba causando los problemas.

Este mismo error exacto se produce si intenta enlazar tarde utilizando la reflexión, si el ensamblado al que está enlazando recibe un nombre seguro o si se cambia su token de clave pública. El error es el mismo aunque en realidad no se encontró ningún ensamblado con el token de clave pública especificado.

Debe agregar el token de clave pública correcto (puede obtenerlo usando sn -T en el dll) para resolver el error. Espero que esto ayude.

La mía fue una situación muy similar a la publicación de Nathan Bedford pero con un ligero giro. Mi proyecto también hizo referencia al dll cambiado de dos maneras. 1) Directamente y 2) Indirectamente haciendo referencia a un componente (biblioteca de clases) que en sí tenía una referencia al dll modificado. Ahora mi proyecto de Visual Studio para el componente (2) hacía referencia a la versión correcta del dll modificado. Sin embargo, el número de versión del componente NO se cambió. Y como resultado, la instalación de la nueva versión del proyecto no pudo reemplazar ese componente en la máquina cliente.

Resultado final: la referencia directa (1) y la referencia indirecta (2) apuntaban a diferentes versiones del dll modificado en la máquina del cliente. En mi máquina de desarrollo funcionó bien.

Resolución: eliminar la aplicación; Eliminar todos los DLLS de la carpeta de la aplicación; Reinstalar. Simple como eso en mi caso.

Dejaré que alguien se beneficie de mi estupidez de corte. Tengo algunas dependencias de una aplicación completamente separada (llamemos a esto App1). Los dll de esa App1 se introducen en mi nueva aplicación (App2). Cada vez que hago actualizaciones en APP1, tengo que crear nuevas dll y copiarlas en App2. Bien. . Me cansé de copiar y pegar entre 2 versiones diferentes de App1, así que simplemente agregué un prefijo 'NEW_' a los dll.

Bueno. . . Supongo que el proceso de compilación escanea la carpeta / bin y cuando coincide con algo incorrectamente, se irrita con el mismo mensaje de error como se indicó anteriormente. Eliminé mi & Quot; new _ & Quot; versiones y construido simplemente dandy.

Mi problema fue copiar el código fuente a una nueva máquina sin detener ninguno de los ensamblados a los que se hace referencia.

Nada de lo que hice solucionó el error, así que de prisa eliminé el directorio BIN por completo. Reconstruí mi código fuente y funcionó a partir de entonces.

Me gustaría simplemente agregar que estaba creando un proyecto básico de ASP.NET MVC 4 y agregué DotNetOpenAuth.AspNet a través de NuGet.Esto resultó en el mismo error después de hacer referencia a un archivo DLL que no coincide para Microsoft.Web.WebPages.OAuth.

Para solucionarlo hice un Update-Package y limpió la solución para una reconstrucción completa.

Eso funcionó para mí y es un poco vago, pero el tiempo es dinero :-P

Recibí este error al compilar el servicio de compilación de Team Foundation Server. Resultó que tenía múltiples proyectos en mi solución usando diferentes versiones de la misma biblioteca agregada con NuGet. Eliminé todas las versiones anteriores con NuGet y agregué la nueva como referencia para todos.

Team Foundation Server coloca todos los archivos DLL en un directorio, y solo puede haber un archivo DLL con un nombre determinado a la vez, por supuesto.

Mi app.config contiene un

<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>

para npgsql. De alguna manera en la máquina del usuario, mi app.exe.config desapareció. No estoy seguro de si todavía era un usuario tonto, un error de instalación o un antivirus ignorado. Reemplazar el archivo resolvió el problema.

Acabo de encontrar otra razón para obtener este error. Limpié mi GAC de todas las versiones de una biblioteca específica y construí mi proyecto con referencia a la versión específica implementada junto con el ejecutable. Cuando ejecuté el proyecto, obtuve esta excepción buscando una versión más nueva de la biblioteca.

El motivo fue política del editor . Cuando desinstalé las versiones de la biblioteca de GAC, también olvidé desinstalar los ensamblados de políticas del editor, por lo que en lugar de usar mi ensamblaje implementado localmente, el cargador de ensamblados encontró la política del editor en GAC que le indicaba que buscara una versión más nueva.

Para mí, la configuración de cobertura de código en " Local.testtesttings " archivo " causado " el problema. Olvidé actualizar los archivos a los que se hacía referencia allí.

Simplemente eliminar el contenido de la carpeta bin de su proyecto y reconstruir la solución resolvió mi problema.

limpiar y reconstruir la solución podría no reemplazar todas las dll del directorio de salida.

lo que sugeriré es intentar cambiar el nombre de la carpeta de " bin " a " oldbin " o " obj " a " oldobj "

y luego intente construir su solución nuevamente.

en caso de que esté utilizando dll de terceros, deberá copiarlos en " bin " o " obj " carpeta después de la compilación exitosa.

espero que esto funcione para usted.

Eliminar manualmente el ensamblado anterior de la ubicación de la carpeta y luego agregar la referencia a los nuevos ensamblados podría ayudar.

Recibí el mismo error ... En mi caso, se resolvió de la siguiente manera:

Al principio, cuando se instaló la aplicación, la gente aquí había usado Microsoft Enterprise Library 4.1 en la aplicación.
En la semana anterior mi máquina tenía el formato & amp; después de eso, hoy, cuando creé esa aplicación, me dio un error de que faltaba el ensamblaje de Enterprise Library.
Luego instalé Microsoft Enterprise Library 5.0 que obtuve en Google como primera entrada de búsqueda.
Luego, cuando creé la aplicación, me dio el error anterior, es decir, la definición de manifiesto del ensamblado ubicado no coincide con la referencia del ensamblaje.
Después de mucho trabajo de búsqueda & amp; análisis, encontré que la aplicación se refería a 4.1.0.0 & amp; la DLL en la carpeta bin era de la versión 5.0.0.0
Lo que hice fue instalar la Microsoft Enterprise Library 4.1.
Se eliminó la referencia anterior (5.0) & amp; agregó la referencia 4.0.
Construyó la aplicación & amp; voila ... funcionó.

Aquí está mi método para solucionar este problema.

Del mensaje de excepción, obtenga el nombre de " problema " biblioteca y el " esperado " número de versión.

Encuentra todas las copias de ese .dll en tu solución, haz clic derecho sobre ellas y comprueba qué versión del .dll es.

Bien, en este ejemplo, mi .dll es definitivamente 2.0.5022.0 (por lo que el número de versión de excepción es incorrecto).

Busque el número de versión que se mostró en el mensaje de excepción en todos los archivos .csproj en su solución. Reemplace este número de versión con el número real de la dll.

Entonces, en este ejemplo, reemplazaría esto ...

<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

... con esto ...

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

¡Trabajo hecho!

En mi caso, el problema era entre la silla y el teclado :-)

Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)

Dos o más ensamblajes diferentes querían usar una versión diferente de la biblioteca DotNetOpenAuth, y eso no sería un problema. Además, en mi computadora local NuGet actualizó automáticamente un web.config:

<dependentAssembly>
    <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
    </dependentAssembly>
    <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
</dependentAssembly>

Luego me di cuenta de que había olvidado copiar / implementar el nuevo web.config en el servidor de producción. Entonces, si tiene una forma manual de implementar web.config, verifique que esté actualizado. Si tiene web.config completamente diferente para el servidor de producción, debe fusionar estas secciones de Ensamblaje dependiente en sincronización después de usar NuGet.

Si alguna vez recibe un error como " La definición de manifiesto del ensamblado ubicado no coincide con la referencia del ensamblaje " y si ha actualizado a través de Proyecto > Administre los paquetes NuGet y la pestaña Actualizar en VS , lo primero que puede hacer es intentar instalar otra versión del paquete después de verificar las versiones de página de NuGet Gallery y ejecutando el siguiente comando desde la consola de Package Manager:

PM> Install-Package YourPackageName -Version YourVersionNumber 
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0

Aunque la respuesta no está directamente relacionada con el paquete en cuestión y se preguntó hace mucho tiempo, es algo genérico, sigue siendo relevante y espero que ayude a alguien.

Recibí este mensaje de error debido a que hacía referencia a un ensamblaje que tenía el mismo nombre que el ensamblado que estaba creando.

Esto se compiló pero sobrescribió el ensamblado al que se hace referencia con el ensamblaje del proyecto actual, lo que causó el error.

Para solucionarlo, cambié el nombre del proyecto y las propiedades del ensamblaje disponibles haciendo clic derecho en el proyecto y seleccionando 'Propiedades'.

En su AssemblyVersion en el archivo AssemblyInfo.cs, use un número de versión fijo en lugar de especificar *. El * cambiará el número de versión en cada compilación. Ese fue el problema de esta excepción en mi caso.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow