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

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, aparece este error.

En palabras simples, no puede encontrar el ensamblado al que se hizo referencia. Asegúrese de que pueda encontrar el ensamblado correcto colocándolo en el GAC o en la ruta de la aplicación. Ver 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 ensamblaje (.dll). Una vez que tenga una lista de resultados, seleccione Ver-> Seleccionar 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 se enumera allí. Este artículo de Microsoft establece que los ensamblados 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. (Ver mi respuesta a esta pregunta para obtener notas sobre la creación de 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 tendrá que habilitar el registro configurando el HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog clave de registro a 1.

Yo mismo me encontré con este problema y descubrí que el problema era algo diferente a lo que los demás 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 en 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 del 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 el número de versión 1.4.1. Ninguno en el GAC, ninguno en las carpetas de aplicaciones ... ninguno en ningún lado. Busqué en todo mi disco duro. Todos los archivos CompanyClasses.dll que tenía eran 1.4.2.

Descubrí que el problema real era que CompanyControls.dll hacía referencia a la versión 1.4.1 de CompanyClasses.dll. Acabo de volver a compilar CompanyControls.dll (después de hacer referencia a CompanyClasses.dll 1.4.2) y este error desapareció para mí.

Lo siguiente redirige cualquier versión de ensamblado a la versión 3.1.0.0. Tenemos un script que siempre actualizará esta referencia en App.config para que nunca más tengamos que lidiar con este problema.

A través de la reflexión, puede obtener el ensamblado publicKeyToken y generar este bloque a partir del 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, pruebe la "solución limpia" y luego reconstruya su proyecto.

Las otras respuestas no funcionarían para mí. Si no le importa la versión y solo desea que su aplicación se ejecute, haga clic derecho en la referencia y configure la 'versión específica' en falso ... Esto funcionó para mí.

Voy a dejar boquiabiertos a todos en este momento. . .

Eliminar todos los <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 parte de la caja negra de mi aplicación hacía referencia a una versión anterior de la biblioteca.

Eliminé el paquete e 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>

Me encontré 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.

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

1. Eliminar 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ó a la perfección.

En mi caso, era una versión antigua 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 se creará un nuevo puntero a los archivos ASP.NET temporales.

Para nosotros, el problema fue causado por otra cosa. El archivo de licencia para los componentes de 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 dio ninguna indicación de qué referencia estaba causando los problemas.

Este mismo error exacto se produce si intenta vincular tardíamente mediante la reflexión, si el ensamblado al que se vincula obtiene un nombre seguro o se cambia su token de clave pública. El error es el mismo aunque en realidad no se ha encontrado 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 la 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 modificado de dos maneras. 1) Directamente e 2) Indirectamente haciendo referencia a un componente (biblioteca de clases) que en sí mismo tenía una referencia a la dll modificada. 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 en sí NO se cambió. Y como resultado, la instalación de la nueva versión del proyecto no reemplazó ese componente en la máquina cliente.

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

Resolución: elimine la aplicación; Elimine todos los archivos DLL de la carpeta de la aplicación; Reinstalar Tan simple como eso en mi caso.

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

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

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

Recibí este error mientras construía sobre el servicio de compilación de Team Foundation Server. Resultó que tenía varios proyectos en mi solución usando diferentes versiones de la misma biblioteca agregadas con NuGet. Eliminé todas las versiones antiguas con NuGet y agregué la nueva como referencia para todas.

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

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

Bien. . . Supongo que el proceso de compilación escanea la carpeta / bin y cuando coincide con algo incorrectamente, muestra el mismo mensaje de error que se indicó anteriormente. Eliminé mis versiones "new_" y se construyó a la perfección.

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 rápidamente eliminé el directorio BIN por completo. Reconstruí mi código fuente y funcionó desde entonces.

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 fue un usuario tonto, un error del instalador o un antivirus descabellado. Reemplazar el archivo resolvió el problema.

Después de probar muchas de las soluciones anteriores sin solución, se redujo a asegurarse de que 'Generar automáticamente redireccionamientos de enlace' estuviera activado dentro de su aplicación en Visual Studio.

Puede encontrar más información sobre cómo habilitar la redirección de enlace automática aquí: https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection

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

La razón fue política del editor. Cuando desinstalé las versiones de la biblioteca de GAC, también olvidé desinstalar los ensamblajes de políticas del editor, así que en lugar de usar mi ensamblaje implementado localmente, el cargador de ensamblajes encontró la política del editor en GAC, que le indicó 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 hace referencia allí.

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

La pregunta ya tiene una respuesta, pero si el problema ha ocurrido con el paquete NuGet en diferentes versiones en la misma solución, puede intentar lo siguiente.

Abra NuGet Package Manager, como puede ver, la versión de mi proyecto de servicio es diferente a otras.

Luego actualice los proyectos que contienen una versión anterior de su paquete.

Es posible que limpiar y reconstruir la solución no reemplace todos los 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 silution nuevamente.

en caso de que esté utilizando 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.

Ninguna solución funcionó para mí. Intenté limpiar la solución del proyecto, eliminar bin, actualizar el paquete, degradar el paquete, etc. 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>

para:

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

Eliminar manualmente el ensamblaje antiguo de la ubicación de la carpeta y luego agregar la referencia a los ensamblajes nuevos 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 de aquí había utilizado Microsoft Enterprise Library 4.1 en la aplicación.
• La semana anterior mi máquina fue formateada y después de eso, hoy, cuando construí esa aplicación, me dio un error de que faltaba el ensamblaje de la biblioteca empresarial.
• 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 del manifiesto del ensamblado ubicado no coincide con la referencia del ensamblaje.
• Después de mucho trabajo de búsqueda y análisis, descubrí 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 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ó.

Este es mi método para solucionar este problema.

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

2. Encuentre todas las copias de ese .dll en su solución, haga clic derecho sobre ellos y verifique 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 .csproj archivos 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 este...

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

Trabajo hecho !

En mi caso, el problema estaba 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 ensamblados 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 me había olvidado de 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 dependientes en sincronización después de usar NuGet.