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

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

System.IO.FileLoadException: No se pudo cargar el archivo o ensamblado 'Utility, Version = 1.2.0.200, Culture = neutral, PublicKeyToken = 764d581291d764f7' o una de sus dependencias. La definición de 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 'Utility, Version = 1.2.0.203, Culture = neutral, PublicKeyToken = 764d581291d764f7' o una de sus dependencias. La definición de 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(la otra es vieja).

¿Alguna sugerencia sobre cómo averiguo qué está tratando de hacer referencia a esta versión anterior de este archivo DLL?

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

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 https://docs.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference .

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-> Elegir detalles ... y luego marque "Versión del archivo". 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 que se encuentran 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 por usted)

Si aún no puede averiguar 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\EnableLogclave 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 ensamblado 'CompanyClasses, Version = 1.4.1.0, Culture = neutral, PublicKeyToken = 045746ba8544160c' o una de sus dependencias. La definición de manifiesto del ensamblado ubicado no coincide con la referencia del ensamblado

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.

Encontré que el verdadero problema 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 la configuración de la aplicación, por lo que nunca tendremos que volver a tratar este problema.

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

Acabo de encontrarme con este problema y el problema era que tenía una copia antigua de .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.

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

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

Get-Project -All | Add-BindingRedirect

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 se produjo al ejecutar una aplicación ASP.NET. La solución fue:

1. Eliminar las carpetas objy binen 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 \ ~ \ Archivos temporales ASP.NET \. 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.

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 usando 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; Vuelva a instalar. 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.

Bien. . . 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é mis versiones "new_" y se creó 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 agregar que estaba creando un proyecto ASP.NET MVC 4 básico y agregué DotNetOpenAuth.AspNet a través de NuGet. Esto dio como resultado el mismo error después de hacer referencia a un archivo DLL que no coincide para Microsoft.Web.WebPages.OAuth.

Para solucionarlo, hice una Update-Packagey limpié la solución para una reconstrucción completa.

Eso funcionó para mí y es un poco flojo, 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 antiguas con NuGet y agregué la nueva como referencia para todos.

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

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 por la cual 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 la política del editor . Cuando desinstalé las versiones de la biblioteca de GAC, también olvidé desinstalar los ensamblados de políticas del editor, así que en lugar de usar mi ensamblado 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 el archivo "Local.testtesttings" "causó" el problema. Olvidé actualizar los archivos a los que se hizo 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" u "obj" a "oldobj"

y luego intente construir su solución nuevamente.

en caso de que esté utilizando archivos DLL de terceros, deberá copiarlos en la carpeta "bin" u "obj" recién creada después de una compilación exitosa.

Espero que esto funcione para usted.

Puede ser útil eliminar manualmente el ensamblaje anterior de la ubicación de la carpeta y luego agregar la referencia a ensamblajes nuevos.

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

• Al principio, cuando se instaló la aplicación, las personas aquí habían usado Microsoft Enterprise Library 4.1 en la aplicación.
• En la semana anterior, mi máquina se formateó y 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 construí la aplicación, me dio el error anterior, es decir, la definición de manifiesto del ensamblado ubicado no coincide con la referencia del ensamblado.
• Después de mucho trabajo de búsqueda y análisis, encontré que la aplicación se refería a 4.1.0.0 y 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) y se agregó la referencia 4.0.
• Construí la aplicación y listo ... funcionó.

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

1. Desde el mensaje de excepción, obtenga el nombre de la biblioteca "problemática" y el número de versión "esperado".

2. Encuentre todas las copias de ese .dll en su solución, haga clic con el botón derecho en ellas y compruebe qué versión del .dll es.

De acuerdo, 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).

3. Busque el número de versión que se mostró en el mensaje de excepción en todos los archivos .csproj de 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 este...

<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 del manifiesto del ensamblado ubicado no coincide con la referencia del ensamblado " y si ha actualizado a través de Proyecto> Administrar paquetes NuGet y pestaña Actualizar en VS , lo primero que puede hacer es instalar otra versión del paquete después de verificar las versiones desde la página de NuGet Gallery y ejecutar 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érica, aún relevante y espero que ayude a alguien.

Ninguna solución funcionó para mí. Intenté limpiar la solución del proyecto, eliminar bin, actualizar el paquete, degradar el paquete y así sucesivamente ... Después de dos horas cargué App.config predeterminado del proyecto con ensamblajes y allí cambié la versión de referencia incorrecta de:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

a:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

Después de esto limpié el proyecto, lo construí de nuevo y funcionó. Sin advertencia no hay problema.

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 de proyectos actual, lo que provoca el error.

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