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


751

Estoy intentando ejecutar algunas pruebas unitarias en una aplicación de formularios Windows Forms de C # (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 de 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 de 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(la otra es vieja).

¿Alguna sugerencia sobre cómo averiguo qué está tratando de hacer referencia a esta versión anterior de este archivo DLL?

Además, creo que ni siquiera tengo este viejo ensamblado en mi disco duro. ¿Hay alguna herramienta para buscar este antiguo ensamblaje versionado?


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

Respuestas:


461

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

En palabras simples, no puede encontrar el ensamblado 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. Consulte también https://docs.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference .


19
pero cuando miro referencias del proyecto, apunta a 1.2.0.203 ... nada parece estar apuntando a 1.2.0.200 más
leora

128
Exactamente: está buscando 1.2.0.203, pero encontró 1.2.0.200. Descubra dónde está ese archivo y reemplácelo con la versión correcta.
Jon Skeet

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

13
Verifique la versión de referencias, y luego mire si es lo mismo en los paquetes.config y Web.config
zdarsky.peter

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

91

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 ensamblado (.dll). Una vez que tenga una lista de resultados, haga 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.

Además, como dijo Lars, verifique su GAC para ver qué versión aparece allí. Este artículo de Microsoft establece que los ensamblajes 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. (Consulte mi respuesta a esta pregunta para obtener notas sobre cómo crear 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 deberá habilitar el registro configurando la HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLogclave de registro en 1.


19
No olvide que la Versión del archivo no forma parte de la identidad de los ensamblados. ¡La versión de ensamblaje 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

Buscar el nombre de archivo resolvió mi problema. ¡Tenía una versión anterior de la dll en mi carpeta ASP.Net temporal y InstallShield la estaba usando en lugar de la versión actualizada! Solución limpia, reconstruir, reiniciar PC no hizo nada. Funcionó bien localmente y explotó cada vez que se implementó.
JumpingJezza

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

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

60

Acabo de encontrarme con este problema yo mismo, y descubrí que el problema era algo diferente de 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ía un error de 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 de 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 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 CompanyClasses.dll que tenía eran 1.4.2.

Encontré que el verdadero problema era que CompanyControls.dll hacía referencia a la versión 1.4.1 de CompanyClasses.dll. Acabo de recompilar CompanyControls.dll (después de hacer referencia a CompanyClasses.dll 1.4.2) y este error desapareció.


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

yo también, su experiencia me provocó dónde necesito mirar y resolví mi problema.
Esen

Otra opción sería abrir el CompanyControlsproyecto, hacer clic derecho en la CompanyClasses.dllreferencia -> propiedades ->SpecificVersion = false
BlueRaja - Danny Pflughoeft

Este es un caso muy frecuente en aplicaciones xamarin. Tuve el proyecto xamarin.forms diferente al proyecto xamarin.droid. Acabo de ver tu publicación y la reconocí.
Batmaci

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

53

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 la configuración de la aplicación, por lo que nunca tendremos que volver a tratar este problema.

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


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

Sin embargo, es mejor no seguir la ruta de reenlace si puede evitarlo. Cuando ese error te muerda, morderá duro.
BanksySan

1
Mi problema fue el hecho de que las redirecciones apuntaban a ensamblajes inexistentes. La App.Config contenía información de ensamblaje de los últimos paquetes NuGet que había instalado. Cuando bajé la versión de estos paquetes más tarde, NO limpié esto. Esta fue una biblioteca de clases estándar .NET que fue golpeada por un proyecto de prueba de unidad de marco 4.7.2. El problema del proyecto de prueba de unidad presentado en tiempo de ejecución ..
D-Sect

@ D-Sect tiene razón. Si su control de origen indica que web.config tiene cambios (porque ha estado jugando con sus NuGets), puede ser prudente respaldar esos redireccionamientos vinculantes fuera de allí. La degradación de NuGets no limpiará las redirecciones de enlace
bkwdesign

45

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


14
Esta suele ser la solución para mí. A menudo, eliminar biny objhacerlo. Básicamente, algo a lo que solía hacer referencia todavía está allí sentado 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

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

Gracias, también funcionó para mí, simplemente borrando la carpeta bin.
The Cookies Dog

Para mí fue suficiente para eliminar la bincarpeta. Sorprendentemente, probé una solución limpia y reconstruí la solución antes sin éxito. A veces un poco extraño.
León

36

Las otras respuestas no funcionarían para mí. 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 ... Esto funcionó para mí. ingrese la descripción de la imagen aquí


8
Esa configuración 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

22

Acabo de encontrarme con este problema y el problema era que tenía una copia antigua de .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.


Simplemente migramos a un servidor diferente, tuvimos este problema porque mantenemos copias de seguridad. Trabajó después de eliminar copias de seguridad. Gracias :)
Jtuck

22

Voy a volar la mente de todos en este momento. . .

Elimine todas las <assemblyBinding>referencias de su archivo .config y luego ejecute este comando desde la consola de NuGet Package Manager:

Get-Project -All | Add-BindingRedirect

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

me ahorraste tiempo 👌👌
Abdu Imam

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

1
La mente explotó oficialmente
BGilman

ese es un pequeño truco agradable
hexagod

21

Agregué un paquete NuGet, solo para darme cuenta de que una porción de recuadro negro de mi aplicación hacía referencia a una versión anterior de la biblioteca.

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

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, suponiendo que el proveedor haya realizado su diligencia debida. Pero buena captura, ya que aparentemente a veces no lo hacen, si así fue como la eliminó.
vapcguy

20

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

  1. Eliminar las carpetas objy binen 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ó perfectamente.


3
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 resolvió. Gracias.
BruceHill

A mí también me funciona. Aún no estoy seguro de por qué esto funciona :(
KangarooWest

14

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 creará un nuevo puntero a los archivos temporales de ASP.NET.


2
Esto funcionó para mí cuando cerré Visual Studio, detuve IIS y eliminé todos los archivos temporales de ASP.NET. 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 el

Utilicé la función de búsqueda del menú Inicio de Windows para encontrar todas las DLL creadas por mi solución y luego eliminé todo el lote, dondequiera que se encontraran. Podría hacerlo sin temor porque solo deberían crearse durante la depuración de Visual Studio. Como VS reconstruirá esas DLL faltantes y nada fuera de mi solución debería hacer referencia a ellas, esta fue una operación "segura" para mí.
Zarepheth

8

Para nosotros, el problema fue causado por algo más. 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 resolvió el problema.

La parte molesta es que el mensaje de error no indicó qué referencia estaba causando los problemas.


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

5

Este mismo error exacto se produce si intenta enlazar tarde usando la reflexión, si el ensamblado al que está enlazando recibe un nombre seguro o si se cambia su token de clave pública. El error es el mismo aunque en realidad no se encontró 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 el dll) para resolver el error. Espero que esto ayude.


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

3
"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 a la carpeta que contiene su ensamblaje y escriba "sn -T <ensamblaje>" donde <ensamblaje> es el nombre completo de la dll. Esto obtiene la información del "token" de la Asamblea. Una vez que tenga esto, cuando realice un enlace tardío con reflexión, ingrese la información del token en la cadena de identificación del ensamblado (es decir, "Assembly = MyAssembly.dll, Public Key Token = <token guid>)
Guy Starbuck

2
Gracias por esta respuesta Recibía este error cuando hacía referencia a una sección de configuración en mi App.ini. Recientemente firmé el ensamblado, por lo que PublicKeyToken = null tuvo que actualizarse con el nuevo token (correcto).
Liam

5

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 cambiado de dos maneras. 1) Directamente y 2) Indirectamente haciendo referencia a un componente (biblioteca de clases) que en sí tenía una referencia al dll modificado. 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 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 del dll modificado en la máquina del cliente. En mi máquina de desarrollo funcionó bien.

Resolución: eliminar la aplicación; Eliminar todos los DLLS de la carpeta de la aplicación; Vuelva a instalar. Simple como eso en mi caso.


4

Dejaré que alguien se beneficie de mi estupidez de corte. Tengo algunas dependencias de una aplicación completamente separada (llamemos a esto App1). Los dll de esa App1 se introducen en mi nueva aplicación (App2). Cada vez que hago 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_' a los dll.

Bien. . . Supongo que el proceso de compilación escanea la carpeta / bin y cuando coincide con algo incorrectamente, se irrita con el mismo mensaje de error como se indicó anteriormente. Eliminé mis versiones "new_" y se creó simplemente dandy.


4

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 de prisa, eliminé el directorio BIN por completo. Reconstruí mi código fuente y funcionó a partir de entonces.


4

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

Para solucionarlo, hice una Update-Packagey limpié la solución para una reconstrucción completa.

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


1
Respuesta similar para mí. Update-Package -reinstallreinstala todos los paquetes NuGet en la misma versión.
Jess

1
Esto es genial; gracias por publicar. Intenté 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 de ellas disponibles
Hambone

4

Recibí este error al compilar el servicio de compilación de Team Foundation Server. Resultó que tenía múltiples 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 coloca todos los archivos DLL en un directorio y, por supuesto, solo puede haber un archivo DLL con un nombre determinado a la vez.


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

4

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 todavía era un usuario tonto, un error de instalación o un antivirus ignorado. Reemplazar el archivo resolvió el problema.


3

Acabo de encontrar otra razón por la cual 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 políticas del editor, así que en lugar de usar mi ensamblado implementado localmente, el cargador de ensamblados encontró la política del editor en GAC que le indicaba que buscara una versión más nueva.


3

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 hizo referencia allí.


3

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


1
Bueno, ¿qué sabes? Me acabas de ayudar con mi miseria, gracias de verdad
Ronny Mahlangu

2

limpiar y reconstruir la solución podría no reemplazar 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 solución nuevamente.

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


1

Puede ser útil eliminar manualmente el ensamblaje anterior de la ubicación de la carpeta y luego agregar la referencia a ensamblajes nuevos.


1

Obtuve el mismo error ... En mi caso, se resolvió de la siguiente manera:

  • Al principio, cuando se instaló la aplicación, las personas aquí habían usado Microsoft Enterprise Library 4.1 en la aplicación.
  • En la semana anterior, mi máquina se formateó y después de eso, hoy, cuando creé esa aplicación, me dio un error de que faltaba el ensamblaje 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 de manifiesto del ensamblado ubicado no coincide con la referencia del ensamblado.
  • Después de mucho trabajo de búsqueda y análisis, encontré 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 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ó.

1

Aquí está mi método para solucionar este problema.

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

ingrese la descripción de la imagen aquí

  1. Encuentre todas las copias de ese .dll en su solución, haga clic con el botón derecho en ellas y compruebe qué versión del .dll es.

ingrese la descripción de la imagen aquí

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 archivos .csproj de 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 !


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

1

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 ensamblajes 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 había olvidado 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 dependiente en sincronización después de usar NuGet.


1

Si alguna vez recibe un error como " La definición del manifiesto del ensamblado ubicado no coincide con la referencia del ensamblado " y si ha actualizado a través de Proyecto> Administrar paquetes NuGet y pestaña Actualizar en VS , lo primero que puede hacer es instalar otra versión del paquete después de verificar las versiones desde la página de NuGet Gallery y ejecutar el siguiente comando desde la consola de Package Manager:

PM> Install-Package YourPackageName -Version YourVersionNumber 
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0

Aunque la respuesta no está directamente relacionada con el paquete en cuestión y se preguntó hace mucho tiempo, es algo genérica, aún relevante y espero que ayude a alguien.


1

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


0

Recibí este mensaje de error debido a que hacía referencia a un ensamblaje que tenía el mismo nombre que el ensamblado que estaba creando.

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

Para solucionarlo, cambié el nombre del proyecto y las propiedades del ensamblaje disponibles haciendo clic derecho en el proyecto y seleccionando 'Propiedades'.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.