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

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 'Utility, Version = 1.2.0.200, Culture = 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 'Utility, Version = 1.2.0.203, Culture = 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 averiguo qué está tratando de hacer referencia a esta versión anterior de este archivo DLL?

Además, no creo que tenga este antiguo ensamblaje en mi disco duro. ¿Hay alguna herramienta para buscar este ensamblaje con versión anterior?

preguntado Oct 18 '08, 11:10

En mi caso, esto sucedió porque tenía dos proyectos cargando la misma DLL con diferentes versiones. (¡Espero que esto ayude a alguien!) -

30 Respuestas

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.

Respondido 22 Feb 20, 01:02

pero cuando miro las referencias del proyecto, apunta a 1.2.0.203 ... ya nada parece apuntar a 1.2.0.200 - leora

Exactamente, es mirando para 1.2.0.203, pero encontrado 1.2.0.200. Averigüe dónde está ese archivo y reemplácelo con la versión correcta. - jon skeet

Hice una pregunta similar aquí y obtuve una solución de trabajo: stackoverflow.com/questions/4187907/… - Michael La Voie

Verifique la versión de referencias y luego mire si es la misma en packages.config y Web.config - zdarsky.peter

Este mensaje me confunde cada vez. Parece estar escrito al revés. Espero que se queje de la versión que solicitó cargar, no de la versión que encontró. ¡Me alegro de no ser el único que se equivoca! - greg maderas

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.

contestado el 23 de mayo de 17 a las 13:05

No olvide que la versión del archivo no forma parte de la identidad de los ensamblados. La versión de ensamblado es, pero no tiene que ser la misma que la versión de archivo. - lars truijens

Si usa fuslogvw para servicios, lea blogs.msdn.com/b/junfeng/archive/2004/02/14/72912.aspx - Nick

La búsqueda del nombre del archivo resolvió mi problema. ¡Tenía una versión antigua de la dll en mi carpeta ASP.Net temporal e InstallShield la estaba usando en lugar de la versión actualizada! Limpiar la solución, reconstruir, reiniciar la PC no hizo nada. Funcionó bien a nivel local y explotó cada vez que se implementó. - saltandojezza

Inmediatamente después de la construcción, mi sitio funciona bien, pero un poco más tarde, surge este problema. - Shavais

Edité esta respuesta para decir versión de ensamblaje en su lugar. - Digno7

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

respondido 17 nov., 09:19

+1 Algo similar me sucedió cuando una de mis DLL hace referencia a una versión anterior de Caliburn Micro. - Jason Massey

a mí también, tu experiencia me provocó dónde debo buscar y solucioné mi problema. - Esen

Otra opción sería abrir el CompanyControls proyecto, haga clic con el botón derecho en el CompanyClasses.dll referencia -> propiedades -> SpecificVersion = false - BlueRaja - Danny Pflughoeft

este es el caso muy a menudo en las aplicaciones xamarin. Tenía un proyecto xamarin.forms diferente al proyecto xamarin.droid. Acabo de ver tu publicación y la reconocí. - Emil

Si CompanyClasses.dll está firmado, entonces SpecificVersion = false solo no lo cortará. Necesitarás un bindingredirect. - Denise Skidmore

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

Respondido el 03 de diciembre de 17 a las 17:12

Esto funcionó para mí. Cambié 'newVersion = 3.3.3' a 'newVersion = 3.1.0' - jward01

Sin embargo, es mejor no seguir la ruta de volver a unir si puedes evitarlo. Cuando ese bicho venga a picarte, morderá con fuerza. - Banksy San

Mi problema fue el hecho de que las redirecciones apuntaban a ensamblados inexistentes. App.Config contenía información de ensamblado de los últimos paquetes de NuGet que había instalado. Cuando bajé estos paquetes más tarde, NO limpió esto. Esta era una biblioteca de clases estándar de .NET que estaba siendo afectada por un proyecto de prueba de unidad de marco 4.7.2. El problema del proyecto de prueba unitaria presentado en tiempo de ejecución. - Secta D

@ D-Sect tiene razón. Si su control de código fuente indica que web.config tiene cambios (porque ha estado jugando con sus NuGets), sería prudente que elimine esos bindingRedirects de allí. La degradación de NuGets no limpiará las redirecciones de enlace: bkwdiseño

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

Respondido 13 Jul 10, 04:07

Esta suele ser la solución para mí. A menudo, eliminando bin y obj hazlo. Básicamente, algo a lo que solía hacer referencia todavía está ahí tratando de satisfacer el mismo requisito. Por ejemplo, una versión anterior es algo a lo que hice referencia directamente y la nueva versión está en NuGet. - david betz

Encontré este problema para varias DLL después de extraer de TFS. Esta solución me lo arregló. - Milo

Trabajó para mi. Eliminó la carpeta bin amd obj y resolvió el problema. - user1619480

Gracias, también funcionó para mí, simplemente eliminando la carpeta bin. - El perro de las galletas

La "solución limpia" no hizo nada por mí. (Microsoft ????) Pero eliminar las carpetas bin y obj lo solucionó. ¡Gracias! - Mmm

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í. enter image description here

Respondido 27 Feb 19, 18:02

Ese ajuste solo tiene efecto en tiempo de compilación. Una vez compilado, necesitará exactamente la misma versión de ensamblaje con la que lo compiló. Ver stackoverflow.com/questions/24022134/… - lars truijens

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

Respondido el 28 de enero de 19 a las 04:01

A mi también me sirvió. Gracias - Oleh Udovytskyi

me salvaste el tiempo 👌👌 - Abdu imán

esto solo funciona cuando el formato de administración de paquetes es packages.config, si está usando 2017 csproj sin packages.config, no funciona :( - ManiVI

Mente oficialmente soplada - BGilman

Actualicé este producto con el tiempo ... a veces solo es necesario eliminar los artefactos y volver a hacerlo. Creo que lo único diferente que pude haber hecho fue crear un nuevo proyecto y seleccionar manualmente los elementos en él ... este comando me salvó de tener que hacer eso ... ¿Algún día tendré que pagar la deuda técnica? Quizás, pero hoy no malvado. - Cazador-Orionnoir

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>

Respondido 01 Abr '17, 09:04

He visto esto donde, al menos para el módulo Entity Framework cuando usa NuGet, si hace clic con el botón derecho en su solución, vaya a Administrar paquetes NuGet para la solución, luego Paquetes instalados> Todos, seleccione ese módulo, seleccione Administrar, puede por lo general, anule la selección de su proyecto. Eso debería limpiar cosas como esta sin tener que hacerlo manualmente, asumiendo que el proveedor hizo su debida diligencia. Pero buena captura, ya que aparentemente a veces no lo hacen, si así es como lo eliminaste. - vapcguy

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.

Respondido el 03 de Septiembre de 09 a las 01:09

Simplemente migramos a un servidor diferente y tuvimos este problema porque guardamos copias de seguridad. Funcionó después de eliminar las copias de seguridad. Gracias :) - jtuck

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.

Respondido 09 Oct 16, 19:10

Gracias, Levi Fuller. Esta respuesta debería estar más arriba; para mi situación fue perfecto! Para mí, este error comenzó cuando hice una copia de seguridad de mi web.config y Visual Studio siguió cargando este archivo de configuración en lugar de la configuración real, incluso después de eliminar la copia duplicada. Esto lo solucionó. Gracias. - brucehill

Funciona para mí también. Sin embargo, todavía no estoy seguro de por qué esto funciona :( - CanguroOeste

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.

Respondido el 15 de Septiembre de 10 a las 18:09

Esto funcionó para mí cuando cerré Visual Studio, detuve IIS y eliminé todos los archivos ASP.NET temporales. Tenga en cuenta que puede haber archivos en la carpeta Framework y Framework64 si está en una máquina de 64 bits, así como en las carpetas .NET 2.0 y 4.0. - Bryan B.

Utilicé la función de búsqueda del menú Inicio de Windows para encontrar todos los archivos DLL creados por mi solución y luego eliminé todo el lote, dondequiera que se encontraran. Podría hacer esto sin miedo porque solo deberían crearse durante mi depuración de Visual Studio. Como VS reconstruirá las DLL que faltan y nada fuera de mi solución debería hacer referencia a ellas, esta fue una operación "segura" para mí. - Zarefet

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.

respondido 23 nov., 09:11

En mi caso, después de actualizar a la nueva versión de DevExpress, el archivo .resx de un formulario contenía referencias a la versión anterior de la biblioteca desinstalada. Tuve que abrir .resx en la vista de código y corregir la versión a una nueva o eliminar las entradas no válidas. - Artemix

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.

Respondido 16 Jul 10, 22:07

Por favor, explique: ¿qué es "sn -T"? ¿Y dónde agrego el token de clave pública? - Moritz Ambos

"sn.exe" es una herramienta que viene con Visual Studio, es una herramienta de línea de comandos que se puede ejecutar desde el símbolo del sistema de Visual Studio. Simplemente ejecute el símbolo del sistema de Visual Studio (desde el menú de inicio), navegue hasta la carpeta que contiene su ensamblado y escriba "sn -T " dónde es el nombre completo de la dll. Esto obtiene la información del "Token" de la Asamblea. Una vez que tenga esto, cuando esté realizando un enlace tardío con reflexión, ingrese la información del token en la cadena de identificación del ensamblaje (es decir, "Assembly = MyAssembly.dll, Public Key Token = ) - tipo starbuck

Gracias por esta respuesta. Recibía este error al hacer referencia a una sección de configuración en mi App.ini. Recientemente había firmado el ensamblado, por lo que PublicKeyToken = null tenía que actualizarse con el token nuevo (correcto). - Liam

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.

Respondido el 16 de Septiembre de 13 a las 12:09

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

respondido 26 nov., 17:00

Respuesta similar para mí. Update-Package -reinstall reinstala todos los paquetes de NuGet en la misma versión. - Cadena

Esto es genial; gracias por publicar. Probé todas estas otras excelentes sugerencias, pero esta fue la solución que funcionó. Gracias a Dios por las personas que todavía están dispuestas a publicar una solución alternativa, incluso cuando hay 80 disponibles. Hambone

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.

Respondido el 03 de diciembre de 17 a las 17:12

Otra forma es hacer clic en "Administrar paquetes NuGet para la solución ..." y actualizar tanto su proyecto de prueba como el proyecto bajo pruebas a la misma versión (la más reciente). - lixon

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.

respondido 13 mar '12, 15:03

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.

Respondido 28 Abr '12, 00:04

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.

Respondido el 03 de diciembre de 17 a las 17:12

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.

enter image description here

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

Respondido el 24 de junio de 20 a las 20:06

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.

Respondido el 01 de junio de 12 a las 14:06

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

respondido 04 mar '13, 09:03

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

Respondido 10 ago 17, 05:08

Bueno, ¿qué sabes? Me acabas de ayudar a salir de mi miseria, gracias de verdad. ronny mahlangu

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.

Ingrese la descripción de la imagen aquí

Respondido el 03 de diciembre de 17 a las 03:12

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.

Respondido el 03 de diciembre de 17 a las 18:12

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>

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.

Respondido 25 ago 19, 17:08

Eliminar manualmente el ensamblaje antiguo de la ubicación de la carpeta y luego agregar la referencia a los ensamblajes nuevos podría ayudar.

Respondido el 06 de junio de 14 a las 10:06

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

Respondido 29 Abr '15, 14:04

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

enter image description here

  1. Encuentra todas las copias de ese .dll en su solución, haga clic derecho sobre ellos y verifique qué versión del .dll es.

enter image description here

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

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

respondido 15 nov., 16:16

¿Qué pasa si mis archivos csproj no tienen una versión referenciada? - Juan Demetriou

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.

Respondido el 03 de diciembre de 17 a las 17:12

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.