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

Question

estoy tratando de hacer algunas pruebas unitarias en C# aplicación de Windows Forms (Visual Studio 2005), y me sale el siguiente error:

System.IO.FileLoadException: Could not load file or assembly 'Utility, Version=1.2.0.200, Culture=neutral, PublicKeyToken=764d581291d764f7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)**

at x.Foo.FooGO()

at x.Foo.Foo2(String groupName_) in Foo.cs:line 123

at x.Foo.UnitTests.FooTests.TestFoo() in FooTests.cs:line 98**

System.IO.FileLoadException: Could not load file or assembly 'Utility, Version=1.2.0.203, Culture=neutral, PublicKeyToken=764d581291d764f7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Miro en mis referencias, y solo tengo una referencia al Utility version 1.2.0.203 (la otra es vieja).

¿Alguna sugerencia sobre cómo averiguo qué está intentando 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 antiguo ensamblado versionado?

Answer 1

El .NET Assembly loader no puede encontrar 1.2.0.203, pero encontró un 1.2.0.200. Este conjunto no coincide con lo solicitado y, por lo tanto, se obtiene este error. En palabras simples, no puede encontrar el ensamblaje 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. También vea http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx.

Answer 2

Puede hacer un par de cosas para solucionar este problema. Primero, use la búsqueda de archivos de Windows para buscar su ensamblaje (.dll) en su disco duro. Una vez que tenga una lista de resultados, haga clic en Ver-> Elegir detalles ... y luego marque "Versión de archivo". Esto mostrará el número de versión en la lista de resultados, para que pueda ver de dónde viene la versión anterior.

Además, como dijo Lars, verifique su GAC para ver qué versión se encuentra allí. This Microsoft article indica 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 reconstruirlos todos. (Consulte mi respuesta al this question para obtener notas sobre cómo crear un archivo por lotes para hacer esto por usted)

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

Answer 3

Me encontré con este problema y el problema fue que tenía una copia anterior 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.

Answer 4

Me acabo de topar con este problema yo mismo, y encontré que el problema era algo diferente de lo que los demás se han topado.

Tenía dos archivos DLL a los que se refería mi proyecto principal: CompanyClasses.dll y CompanyControls.dll. Que estaba recibiendo un dicho error de tiempo de ejecución:

Could not load file or assembly 'CompanyClasses, Version=1.4.1.0, Culture=neutral, PublicKeyToken=045746ba8544160c' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference

El problema era que yo 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 de CompanyClasses.dll que tenía eran 1.4.2.

El problema real, me enteré, fue que CompanyControls.dll hace referencia a la versión 1.4.1 de CompanyClasses.dll. Recién compruebe CompanyControls.dll (después de hacer que haga referencia a CompanyClasses.dll 1.4.2) y este error desapareció.

Answer 5

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.La eliminación de 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.

Answer 6

Intente agregar lo que falta al caché de ensamblados global.

Answer 7

Si está usando Visual Studio, intente con "limpiar la solución" y luego reconstruya su proyecto.

Answer 8

Se lanza exactamente el mismo error si intenta vincular tarde utilizando la reflexión, si el conjunto al que se está vinculando obtiene un nombre seguro o si se ha cambiado su token de clave pública. El error es el mismo aunque no se haya encontrado ningún conjunto con el token de clave pública especificado.

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

Answer 9

La mía era 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 al hacer referencia a un componente (biblioteca de clases) que tenía una referencia al dll cambiado. Ahora mi proyecto de Visual Studio para el componente (2) hacía referencia a la versión correcta del dll cambiado. Sin embargo, el número de versión del compñente no se modificó. 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) señalaban las diferentes versiones del dll cambiado en la máquina del cliente. En mi máquina de desarrollo funcionó bien.

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

Answer 10

Haga clic con el botón derecho en la referencia en VS establezca la propiedad "Versión específica" en True.

Answer 11

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 ASP.NET temporales.

Answer 12

Recibí este mensaje de error al hacer referencia a un ensamblaje que tenía el mismo nombre que el ensamblado que estaba construyendo.

Esto compiló pero sobrescribió el ensamblaje al que se hace referencia con el ensamblado de proyectos actual, lo que ocasionó el error.

Para solucionarlo Cambié el nombre del proyecto y las propiedades de ensamblaje disponibles haciendo clic con el botón derecho en el proyecto y seleccionando "Propiedades".

Answer 13

Voy a dejar que alguien se beneficie de mi estupidez de corte. Tengo algunas dependencias a una aplicación completamente separada (llamémosla App1). Los archivos DLL de esa aplicación1 se extraen en mi nueva aplicación (App2). Cada vez que realizo 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_' al dll.

Bien. . . Supongo que el proceso de compilación escanea la carpeta/bin y cuando coincide incorrectamente con algo, aparece con el mismo mensaje de error que el anterior. Eliminé mis versiones "nuevas" y las compilé solo a la perfección.

Answer 14

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

Nada de lo que hice corrigió el error, así que a toda prisa, eliminé por completo el directorio BIN. Reconstruí mi código fuente y funcionó de ahí en adelante.

Answer 15

Acabo de encontrar otro motivo 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 ejecuto el proyecto recibí esta excepción en busca de una versión más nueva de la biblioteca.

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

Answer 16

Tuve un problema similar al intentar actualizar un archivo DLL de mi sitio web.

Este error estaba ocurriendo, cuando simplemente copié este archivo DLL en la carpeta bin a través de FTP.

que resuelven este problema:

1. detener el sitio web;
2. se necesita copiar el archivo DLL/archivos DLL;
3. iniciar el sitio web

Answer 17

Mi app.config contiene una

<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 aún así. Reemplazar el archivo resolvió el problema.

Answer 18

Lo siguiente redirecciona 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 lidiar con este problema nuevamente.

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

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

Answer 19

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

Answer 20

Me enfrenté al mismo problema mientras ejecutaba las pruebas de mi unidad.

El error indica claramente que el problema es: cuando intentamos cargar el ensamblado, el cargador de ensamblados .NET intenta cargar sus conjuntos referidos basándose en sus datos de manifiesto (nombre del ensamblado, token de clave pública, versión).

Para comprobar los datos del manifiesto:

1. Abra el símbolo del sistema de Visual Studio,
2. Tipo 'ildasm' y arrastra la necesidad de ensamblaje a la ventana y abrir la vista ILDASM manifiesto.A veces, MANIFEST contiene un ensamblaje con dos versiones, una versión anterior y otra nueva (como Utility, Version=1.2.0.200 y Utility, Version=1.2.0.203). En realidad, el conjunto referido es Utility, Version=1.2.0.203(new version), pero dado que el manifiesto contiene incluso Utility, Version=1.2.0.200(old version), el cargador de ensamblados .NET intenta descubrir este archivo DLL versionado, no puede encontrar y arroja una excepción.

Para resolver esto, simplemente arrastre cada uno de los ensamblados dependientes del proyecto a la ventana ILDASM por separado y verifique qué ensamblaje dependiente contiene los datos del manifiesto con la versión del ensamblaje anterior. Simplemente reconstruya este ensamblaje dependiente y remítalo a su proyecto.

Answer 21

Si no se preocupan por la versión y sólo quiere que su aplicación se ejecute a continuación, haga clic derecho en la referencia y establecer 'versión específica' false. Las otras soluciones no funcionarían para mí.

Answer 22

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

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

que trabajó para mí y es una especie de una forma perezosa, pero el tiempo es dinero :-P

Answer 23

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

Answer 24

me encontré con este problema durante el uso de un repositorio de paquetes interna. Agregué el paquete principal al repositorio interno, pero no las dependencias del paquete. Asegúrese de agregar todas las dependencias, dependencias de dependencias, recursivas, etc. a su repositorio interno también.

Answer 25

he añadido un paquete de NuGet, sólo para darse cuenta una parte de recuadro negro de mi solicitud se refería a una versión anterior de la biblioteca.

que eliminar el paquete y se hace referencia estática archivo DLL de la versión anterior, pero el archivo web.config no se ha actualizado 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 recurrido a cuando he desinstalado 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> 

Answer 26

borrar manualmente el conjunto usado de ubicación de la carpeta y luego añadir la referencia a nuevos montajes podría ayudar.

Answer 27

que tenían el mismo problema hoy, que me impidió realizar Añadir a la migración después de hacer cambios en el marco de la entidad.

tenía dos proyectos en mi solución, llamémosles "Cliente" y "Datos" - un proyecto de biblioteca de clases que celebró mis modelos EF y el contexto. El cliente hizo referencia al proyecto de datos.

que había firmado ambos proyectos, y luego más tarde realizado cambios en un modelo de EF. Después de eliminar la firma, pude agregar las migraciones y luego pude volver a firmar el proyecto.

espero que esto puede ser útil para alguien, ahorrándoles de frustración prolongada ..

Answer 28

he tenido este problema después de comenzar a usar InstallShield.Aunque el orden de compilación mostró que el proyecto de instalación era el último que se estaba construyendo fuera de servicio.

corregí esto haciendo dependientes de cualquier otro proyecto sobre ella - esto obligó a la instalación de la construcción de la última y por lo tanto eliminado mi desajuste montaje. Espero que esto ayude.

Answer 29

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 diversos montajes querían utilizar una versión diferente de la biblioteca DotNetOpenAuth, y eso no sería un problema. Por otra parte, en mi equipo local, un web.config se actualiza automáticamente por NuGet:

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

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

Answer 30

me dieron el mismo error ... En mi caso se resolvió de la siguiente manera:

• Al principio, cuando se instaló la aplicación a continuación, la gente de aquí había utilizado Microsoft Enterprise Library 4.1 en la aplicación.
• En la semana anterior mi máquina se ha formateado & después de que hoy en día cuando construí esa aplicación, entonces me dio un error que el montaje Enterprise Library no se encuentra.
• 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 ensamblaje ubicado no coincide con la referencia del ensamblaje.
• Después de mucho de un trabajo de búsqueda & análisis, he encontrado que la aplicación se refería 4.1.0.0 & el archivo DLL en la carpeta bin era de la versión 5.0.0.0
• lo que hice fue entonces he instalado la biblioteca Microsoft Enterprise 4.1 .
• retira la referencia anterior (5.0) & añadió la referencia 4.0.
• Construyó la aplicación & voila ... funcionó.

Answer 31

Recibí este error al construir en 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 agregada con NuGet. Eliminé todas las versiones antiguas con NuGet y agregué la nueva como referencia para todos.

Team Foundation Server pone todos los archivos DLL en un directorio, y sólo puede haber un archivo DLL de un cierto nombre a la vez, por supuesto.

Answer 32

Esto también puede ocurrir si está utilizando ambos AssemblyInfo.cs con las etiquetas AssemblyVersion y su archivo .csproj tiene con un valor diferente. Al hacer coincidir AssemblyInfo o eliminar la sección todos juntos, el problema desaparece.

Answer 33

En mi caso, este error se produjo mientras se ejecuta una aplicación ASP.NET. La solución fue:

1. Eliminar los obj y bin carpetas en la carpeta del proyecto

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

Answer 34

Este es mi método para solucionar este problema.

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

2. Encuentra todas las copias de ese .dll en su solución, haga clic en ellos, y comprobar la versión del archivo .dll que es.

bien, así que en este ejemplo, mi .dll es definitivamente 2.0.5022.0 (por lo que el número de versión de excepción está mal).

3. Buscar el número de versión que se muestra en el mensaje de excepción en todas las .csproj archivos en su solución. Reemplace este número de versión con el número real de la dll.

Por lo tanto, en este ejemplo, me gustaría sustituir este ...

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

Answer 35

OK, una respuesta más. Anteriormente, creé mi aplicación como de 64 bits y cambié la ruta de salida (Proyecto/Propiedades/Compilación/Salida/Ruta de salida) en consecuencia. Recientemente cambié la aplicación a 32 bits (x86), creando una nueva ruta de salida. Creé un acceso directo al lugar donde creí el .exe compilado. No importa lo que haya cambiado sobre la fuente, obtuvo el error manifiesto de no coincidencia. Después de aproximadamente una hora de frustración, casualmente comprobé la fecha/hora del archivo .exe, vi que era obvio que hacía referencia a viejos .dll. Estaba compilando la aplicación en el directorio anterior y mi atajo hacía referencia a la más reciente. Se modificó la ruta de salida a donde debe ir el archivo .exe , se ejecutó el acceso directo y el error desapareció. (frente de palmadas)

Answer 36

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 el Administrador de paquetes NuGet, como puede ver, la versión de mi proyecto de servicio es diferente a otras.

A continuación, actualice los proyectos que contengan una versión anterior de su paquete.

Answer 37

Sólo Para eliminar el contenido de la carpeta bin de su proyecto y reconstruir la solución solucionado mi problema.

Answer 38

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

lo que voy a sugerir es tratar de cambiar el nombre de la carpeta en "bin" para "oldbin" o "obj" a "oldobj"

e intente construir su silution nuevo.

en caso de que esté utilizando archivos dll de terceros que deberá copiar en la carpeta "bin" u "obj" recién creada después de la compilación correcta.

Espero que esto funcione para usted.

Answer 39

El problema era que había viejos dll's dployed que se eliminaron en una nueva compilación. Para solucionarlo, acabo de marcar la casilla para eliminar archivos adicionales en el destino al publicar. Remove additional files at destination