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


Estoy intentando ejecutar algunas pruebas unitarias en una aplicación C # Windows Forms (Visual Studio 2005), y recibo 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 ensamblaje ubicado no coincide con la referencia de ensamblaje. (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 ensamblaje ubicado no coincide con la referencia de ensamblaje. (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á intentando hacer referencia a esta versión anterior de este archivo DLL?

Además, no creo que tenga este ensamblaje antiguo en mi disco duro. ¿Hay alguna herramienta para buscar este antiguo ensamblado versionado?


591
2017-10-18 13:16


origen


Respuestas:


El cargador de ensamblado .NET 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. Ver también http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx.


379
2017-10-18 13:39



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 figura allí. Este artículo de Microsoft indica que los ensamblados 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 reconstruirlos todos. (Ver mi respuesta a esta pregunta para 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 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 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog clave de registro para 1.


85
2017-10-20 21:31



Acabo de toparme con este problema y descubrí que el problema era diferente de lo que los demás se toparon.

Tenía dos DLL a los que se refería mi proyecto principal: CompanyClasses.dll y CompanyControls.dll. Me estaba dando un error en tiempo de ejecución que decía:

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

El problema fue que no tenía ningún archivo CompanyClasses.dll en mi sistema con un número de versión de 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 verdadero problema, descubrí, era que CompanyControls.dll hacía 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ó.


52
2017-11-17 19:15



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

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


39
2017-11-02 00:34



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


32
2017-07-13 03:27



Si no te importa la versión y solo quieres que se ejecute tu aplicación, haz clic derecho en la referencia y establece "versión específica" en falso. Las otras soluciones no funcionarían para mí. enter image description here


31
2018-06-28 17:21



Me encontré con este problema y el problema fue que tenía una copia anterior del .dll en mi directorio de depuración de aplicaciones. Es posible que también desee verificar allí (en lugar del GAC) para ver si lo ve.


20
2017-09-03 00:00



Agregué un paquete NuGet, solo para darme cuenta de que una porción de la caja negra de mi aplicación estaba haciendo referencia a una versión anterior de la biblioteca.

Quité 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 revertido 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>

16
2018-03-05 16:22



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.


13
2017-09-15 17:07



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

  1. Borrar el obj y bin carpetas en la carpeta del proyecto

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


12
2017-10-09 18:34