c# - referencia - no se puede cargar el archivo o ensamblado system net http formatting
La definición del manifiesto del ensamblaje localizado no coincide con la referencia del ensamblaje (30)
Acabo de encontrar este problema y el problema era que tenía una copia antigua de .dll en mi directorio de depuración de la aplicación. Es posible que también desee consultar allí (en lugar del GAC) para ver si lo ve.
Estoy intentando ejecutar algunas pruebas unitarias en una aplicación de formularios Windows Forms (Visual Studio 2005) y obtengo el siguiente error:
System.IO.FileLoadException: No se pudo cargar el archivo o el ensamblaje ''Utilidad, Versión = 1.2.0.200, Culture = neutral, PublicKeyToken = 764d581291d764f7'' o una de sus dependencias. La definición del manifiesto del ensamblaje localizado no coincide con la referencia del 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 el ensamblaje ''Utilidad, Versión = 1.2.0.203, Culture = neutral, PublicKeyToken = 764d581291d764f7'' o una de sus dependencias. La definición del manifiesto del ensamblaje localizado no coincide con la referencia del ensamblaje. (Excepción de HRESULT: 0x80131040)
Busco en mis referencias y solo tengo una referencia a la Utility version 1.2.0.203 (la otra es antigua).
¿Alguna sugerencia sobre cómo descubro lo que se intenta hacer referencia a esta versión anterior de este archivo DLL?
Además, no creo que tenga este antiguo conjunto en mi disco duro. ¿Hay alguna herramienta para buscar este antiguo ensamblaje versionado?
Acabo de encontrar otra razón 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 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 la política del editor, por lo que, en lugar de utilizar mi ensamblaje implementado localmente, el cargador de ensamblajes encontró la política del editor en la GAC, que le pidió que buscara una versión más nueva.
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.
Quité 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 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>
Aquí está mi método de solucionar este problema.
- Desde el mensaje de excepción, obtenga el nombre de la biblioteca "problema" y el número de versión "esperado".
- Encuentre todas las copias de ese archivo .dll en su solución, haga clic con el botón derecho en ellas y verifique qué versión del archivo .dll es.
Bien, 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).
- Busque el número de versión que se mostró en el mensaje de excepción en todos los archivos .csproj 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 !
Con solo eliminar el contenido de la carpeta bin de su proyecto y reconstruir la solución, resolví mi problema.
Dejaré que alguien se beneficie de mi estupidez. Tengo algunas dependencias para una aplicación completamente separada (llamemos a esta App1). Los archivos DLL de esa App1 se insertan en mi nueva aplicación (App2). Cada vez que hago actualizaciones en la APP1, tengo que crear nuevos archivos DLL y copiarlos en la App2. Bien. . Me cansé de copiar y pegar entre 2 versiones diferentes de App1, así que simplemente agregué un prefijo ''NEW_'' a los archivos DLL.
Bien. . . Supongo que el proceso de compilación analiza la carpeta / bin y cuando encuentra algo incorrecto, aparece el mismo mensaje de error como se indicó anteriormente. Eliminé mis versiones "new_" y construí simplemente dandy.
El .NET Assembly loader no puede encontrar 1.2.0.203, pero sí encontró un 1.2.0.200. Este ensamblaje no coincide con lo que se solicitó y, por lo tanto, aparece este error. En palabras simples, no puede encontrar el ensamblaje al que se hizo referencia. Asegúrese de que puede 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 .
Eliminar manualmente el conjunto anterior de la ubicación de la carpeta y luego agregar la referencia a nuevos conjuntos podría ayudar.
En mi caso el problema fue 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 conjuntos diferentes querían utilizar una versión diferente de la biblioteca DotNetOpenAuth, y eso no sería un problema. Además, en mi computadora local, un web.config fue actualizado 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>
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 manera manual de implementar web.config, verifique que esté actualizado. Si tiene un web.config completamente diferente para el servidor de producción, tiene que fusionar estas secciones dependientes de Ensamblaje en sincronización después de usar NuGet.
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 se creará un nuevo puntero a los archivos temporales de ASP.NET.
En mi caso, este error ocurrió al ejecutar una aplicación ASP.NET. La solución fue:
- Eliminar las carpetas
objybinen 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 borrar esos directorios, todo funcionó perfectamente.
En su archivo AssemblyVersion en AssemblyInfo.cs, use un número de versión fijo 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.
Este mismo error se produce exactamente si intenta realizar un enlace tardío utilizando la reflexión, si el ensamblaje al que está enlazando recibe un nombre seguro o si su token de clave pública ha cambiado. El error es el mismo, aunque en realidad no se encuentra 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 de Nathan Bedford, pero con un ligero giro. Mi proyecto también hizo referencia a la dll cambiada de dos maneras. 1) Directamente y 2) Indirectamente al hacer referencia a un componente (biblioteca de clases) que a su vez tenía una referencia a la dll modificada. Ahora, mi proyecto de Visual Studio para el componente (2) hizo referencia a la versión correcta de la dll modificada. Sin embargo, el número de versión del propio 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 de la dll modificada en la máquina cliente. En mi máquina de desarrollo funcionó bien.
Resolución: Eliminar aplicación; Eliminar todos los DLLS de la carpeta de la aplicación; Reinstalar.Simple como eso en mi caso.
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 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 desde el propio 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á.
Me encontré con este problema mientras utilizaba un repositorio de paquetes interno. Yo había agregado 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.
Me gustaría agregar que estaba creando un proyecto básico de ASP.NET MVC 4 y agregé DotNetOpenAuth.AspNet a través de NuGet. Esto resultó en el mismo error después de que hice referencia a un archivo DLL que no coincide para Microsoft.Web.WebPages.OAuth.
Para solucionarlo, hice un Update-Package y limpié la solución para una reconstrucción completa.
Eso me funcionó y es un poco perezoso, pero el tiempo es dinero :-P
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 problema de instalación o un antivirus descartado todavía. Reemplazando el archivo solucionó el problema.
Mi problema fue copiar el código fuente a una máquina nueva sin tener que desplazar ninguno de los ensamblajes a los que se hace referencia.
Nada de lo que hice corrigió el error, así que, apresuradamente, eliminé el directorio BIN por completo. Reconstruí mi código fuente, y funcionó a partir de entonces.
Para mí, la configuración de cobertura de código en el archivo "Local.testtesttings" "causó" el problema. Olvidé actualizar los archivos que fueron referenciados allí.
Para nosotros, el problema fue causado por otra cosa. 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 solucionó el problema.
La parte molesta es que el mensaje de error no dio ninguna indicación de qué referencia estaba causando los problemas.
Puedes 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, haga clic en 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.
También, como dijo Lars, revisa tu GAC para ver qué versión se encuentra allí. Este artículo de Microsoft indica que los ensamblajes encontrados en la 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 ver las 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 envía con Visual Studio para obtener más información sobre los errores de enlace. Microsoft tiene información sobre esta herramienta here . Tenga en cuenta que tendrá que habilitar el registro configurando la clave de registro HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Fusion/EnableLog en 1.
Recibí el mismo error ... En mi caso se resolvió de la siguiente manera:
- Al principio, cuando se instaló la aplicación, las personas aquí usaron Microsoft Enterprise Library 4.1 en la aplicación.
- En la semana anterior, mi máquina fue formateada y después de eso, cuando construí esa aplicación, me dio el error de que falta el ensamblado 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 del manifiesto del ensamblaje localizado no coincide con la referencia del ensamblaje.
- Después de una gran parte de un trabajo de búsqueda y análisis, encontré que la aplicación hacía referencia a 4.1.0.0 y que 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ó.
Recibí este error al desarrollar 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 anteriores con NuGet y agregué la nueva como referencia para todos.
Team Foundation Server coloca todos los archivos DLL en un directorio, y solo puede haber un archivo DLL con un nombre determinado a la vez, por supuesto.
Recibí este mensaje de error debido a que hacía referencia a un ensamblaje que tenía el mismo nombre que el ensamblaje que estaba construyendo.
Esto compiló pero sobrescribió el ensamblaje al que se hace referencia con el ensamblado de los proyectos actuales, lo que provoca 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''.
Si está utilizando Visual Studio, intente "solución limpia" y luego reconstruya su proyecto.
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. Las otras soluciones no funcionarían para mí.
Simplemente me encontré con este problema, y descubrí que el problema era algo diferente a 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í un error en el tiempo de ejecución que decía:
No se pudo cargar el archivo o el ensamblaje ''CompanyClasses, Version = 1.4.1.0, Culture = neutral, PublicKeyToken = 045746ba8544160c'' o una de sus dependencias. La definición del manifiesto del ensamblaje localizado no coincide con la referencia del ensamblaje
El problema era que no tenía ningún archivo CompanyClasses.dll en mi sistema con un número de versión de 1.4.1. Ninguna en el GAC, ninguna en las carpetas de aplicaciones ... ninguna en ninguna parte. Busqué todo mi disco duro. Todos los archivos de CompanyClasses.dll que tenía eran 1.4.2.
El problema real, encontré, fue 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 tenerlo como referencia a CompanyClasses.dll 1.4.2) y este error desapareció para mí.
Tuve el mismo problema hoy que me impidió realizar Add-Migration después de realizar cambios en Entity Framework.
Tenía dos proyectos en mi solución, llamémoslos "Cliente" y "Datos", un proyecto de biblioteca de clase que contenía mis modelos y contexto EF. El cliente hizo referencia al proyecto de datos.
Firmé ambos proyectos y luego realicé cambios en un modelo EF. Después de eliminar la firma, pude agregar las migraciones y luego pude firmar nuevamente el proyecto.
Espero que esto pueda ser útil para alguien, evitándoles una frustración prolongada.
limpiar y reconstruir la solución puede que no reemplace 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 silencia de nuevo.
En caso de que esté utilizando archivos DLL de terceros, deberá copiarlos en la carpeta "bin" u "obj" recién creada después de la compilación exitosa.
Espero que esto funcione para usted.