.Net que elige una versión de ensamblaje referenciada incorrecta

Acabo de copiar un proyecto existente en una máquina nueva para comenzar a desarrollarlo y me he encontrado con un problema con la versión de uno de mis ensambles a los que se hace referencia (una DLL de telerik, como sucede).

El proyecto originalmente hacía referencia a una versión anterior del ensamblado (vamos a llamarlo v1.0.0.0). Mi nueva máquina tiene instalada la última versión del ensamblaje, así que pensé que la había actualizado (llamemos a la nueva versión v2.0.0.0).

Ahora, aquí está el problema: si copio el viejo v1.0.0.0 dll a la carpeta del proyecto y lo agrego como referencia, el sitio web se inicia sin ningún problema. Si elimino esa referencia (y también elimino la DLL anterior de mi sistema) y agrego la nueva versión (v2.0.0.0), la página muestra la siguiente excepción:

No se pudo cargar el archivo o ensamblado 'XXXXXX, Versión = 1.0.0.0, Cultura = neutral, PublicKeyToken = 121fae78165ba3d4' 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)

Claramente, el código está buscando la versión desactualizada y no puede encontrarla. ¿Pero por qué?

Busqué la carpeta de la solución para ese número de versión y no pude encontrar una sola referencia. Revisé dos veces el texto del archivo .csproj y encontré que la versión muestra correctamente la última versión y HintPath muestra correctamente la ruta a la nueva DLL. Además, debido a que no instalé la antigua DLL en el sistema, no aparece en mi GAC (aunque v2.0.0.0 sí, como se esperaba).

Luego habilité el visor de registro de fusión para tratar de descubrir por qué está buscando esa versión anterior, pero no tuve suerte:

Assembly Load Trace: The following information can be helpful to determine why the assembly 'XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4' could not be loaded.


=== Pre-bind state information ===
LOG: User = MyComp\me
LOG: DisplayName = XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
 (Fully-specified)
LOG: Appbase = file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/
LOG: Initial PrivatePath = d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\bin
Calling assembly : WebApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\web.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX.DLL.
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX/XXXXXX.DLL.
LOG: Attempting download of new URL file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/bin/XXXXXX.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

Todo lo que dice es que comienza buscando ese viejo ensamblaje. Intenté encontrar una solución en línea y vi esta pregunta SO similar , pero parece ser exactamente lo contrario de mi problema. El programa de ese interrogador estaba encontrando la DLL incorrecta en lugar de la referenciada. Mientras que mi problema es que el programa está buscando misteriosamente la DLL incorrecta y no puede encontrarla cuando se puede encontrar localmente la correcta en la carpeta bin y en el GAC.

¿Por qué el mío está buscando la versión anterior? ¿Dónde más puedo buscar para encontrar esta mala referencia?

Supongo que otro ensamblaje que está utilizando hace referencia a la dll anterior. ¿Está familiarizado con todas las demás referencias de proyectos que se utilizan y alguna de ellas tiene una referencia a los dlls de Telerik?

¿Puede poner una redirección vinculante en su archivo web.config como este?

<dependentAssembly>
 <assemblyIdentity name="Telerik" publicKeyToken="121fae78165ba3d4"/>
 <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

Estoy con Chris Conway en este caso (lo voté). El problema es que está haciendo referencia a uno de los ensamblajes de telerik en su proyecto que hace referencia a otro que no está allí.

Lo primero: no instalaría CUALQUIER ensamblador de proveedores (es decir, telerik) en el GAC. Las cosas de Telerik se compilan en solo dos ensamblajes de todos modos (telerik.web.design y telerik.web.ui). Simplemente implemente aquellos con la aplicación.

Segundo, en cada uno de sus archivos .proj (como .csproj) habrá un <reference include..>archivo que apunte al archivo Telerik.Web.UI. Esto normalmente contiene un número de versión. Asegúrese de que el ensamblaje que coloque en la carpeta bin coincida con esa versión.

Tercero, asegúrese de que TODOS sus proyectos utilicen el último ensamblaje. También asegúrese de que estén agarrando el ensamblaje desde una ruta local en lugar del GAC. (Realmente no me gusta el GAC. Ha causado un sinfín de problemas en algunos proyectos en los que he estado). Normalmente tenemos una carpeta "Ensamblajes" que todos los proyectos usan para referencias de ensamblajes externos.

Cuarto, Visual Studio busca automáticamente en su gac cada vez que se carga un proyecto de sitio web y vuelve a establecer las ubicaciones de ensamblaje si encuentra algo en el gac. No recuerdo si alguna vez hace esto para proyectos de aplicaciones web, pero no he tenido el problema en mucho tiempo con ellos. Esto puede causar problemas similares durante la implementación.

Quinto, puede volver a vincular los números de versión para ensamblados en web.config. En la runtime/assemblybindingsección puede usar algo como lo siguiente que lleva a cada ensamblaje de telerik desplegado en 2008 hacia adelante y lo señala a una versión muy particular:

  <dependentAssembly>
    <assemblyIdentity name="Telerik.Web.UI" publicKeyToken="121fae78165ba3d4" />
    <bindingRedirect oldVersion="2008.0.0.0-2020.0.0.0" newVersion="2010.02.0713.35" />
  </dependentAssembly>

Intenté la mayoría de las respuestas pero aún así no pude hacerlo funcionar. Esto funcionó para mí:

haga clic derecho en referencia -> propiedades -> cambie 'Versión específica' a falso.

Espero que esto ayude.

Tratar:

• limpieza de archivos de proyectos temporales
• limpieza de compilación y archivos obj
• limpieza de versiones antiguas instaladas en C:\Users\USERNAME\.nuget\packages\

Eso funcionó para mí.

1. Vaya a C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG
2. Encuentra el archivo machine.config
3. abrir en el bloc de notas
4. encontrar conflicto dll
5. Eliminar esto y guardar.

ensamblajes de compilación

addassembly = dllName, Version = 1.0.0000.0000 Culture = neutral, PublicKeyToken = "QWEWQERWETERY"

compilación de ensamblajes

funciona para mi.

Esta no es una respuesta clara de por qué, pero tuvimos este problema, aquí están nuestras circunstancias y lo que lo resolvió:

Dev 1:

La solución contiene el proyecto A que hace referencia a un paquete NuGet y un proyecto MVC que hace referencia al proyecto A. Restauración de paquetes NuGet habilitada, luego actualiza el paquete NuGet. Recibí un error de tiempo de ejecución quejándose de que no se puede encontrar la lib NuGet, pero el error es que está buscando la versión anterior no actualizada. Solución (y esto es ridículo): establezca un punto de interrupción en la primera línea de código en el proyecto MVC que llama al Proyecto A. Ingrese con F11. Resuelto: nunca más tuve un problema.

Dev 2:

Misma solución y proyectos, pero el punto de interrupción del conjunto mágico y el paso en la solución no funcionan. Busqué en todas partes redirecciones de versiones u otras malas referencias a este paquete Nuget, eliminé el paquete y lo reinstalé, borré bin, obj, Asp.Net Temp, nada lo resolvió. Finalmente, renombrado Proyecto A, ejecutó el proyecto MVC - arreglado. Renombrado de nuevo a su nombre original, se mantuvo fijo.

No tengo ninguna explicación de por qué funcionó, pero sí nos sacó de una sacudida seria.

¿Tiene algún otro proyecto en esa solución? (Puede haber otro proyecto haciendo referencia a una versión anterior) Por lo general, en VS, la dependencia de dll abarca todos los proyectos de la solución.

Mi problema era que los ensamblajes antiguos estaban en la carpeta _bin_deployableAssemblies en la aplicación web. Esto significaba que las asambleas antiguas sobrescribían las asambleas GAC al construir el proyecto.

En caso de que ahorre a alguien más 3 horas ... mi caso fue un poco diferente. Mi código usaba DevExpress v11.1 v11.1.4.0. Tenía todo referenciado correctamente en mi código. Pero el generador de perfiles de memoria .net instaló DevExpress v11.1 v11.1.12.0 en el GAC. De hecho, no fueron los componentes a los que hice referencia sino los que hicieron referencia internamente los que fallaron. Por más que lo intente, el GAC siempre se verifica primero. Se compiló y funcionó bien, pero no pude ver el diseñador de formularios de victorias y el seguimiento de la pila no fue de ninguna ayuda. Finalmente desinstalé el perfilador de memoria .net y todo fue restaurado.

Tuve un problema similar y tuve que eliminar todo de las carpetas bin y obj y reconstruir para superar mi problema. Espero que esto ayude.

Si tiene este problema al probar y / o depurar la aplicación desde el entorno de Visual Studio (ASP.NET Development Server), es necesario eliminar todos los archivos temporales en la carpeta del sitio web de desarrollo. Para saber dónde está esa carpeta, busque el ícono del Servidor de desarrollo ASP.NET en el ícono de la bandeja de Windows (debe tener un título como este: Servidor de desarrollo ASP.NET - Puerto ####), haga clic derecho en el ícono y seleccione Mostrar Detalles; Luego, el campo Ruta física le dirá cuál es la carpeta temporal, todos los elementos deben eliminarse para resolver el problema. Cree y ejecute nuevamente el sitio web y el problema debe resolverse (nuevamente, resuelto para el Entorno de desarrollo).

Tuve el mismo problema con diferentes ensamblados que hacen referencia a diferentes versiones de Newtonsoft.json. La solución que funcionó para mí fue ejecutar update-package desde Nuget Package Manager Console.

Este error fue algo engañoso: estaba cargando algunas DLL que requerían que se especificara la arquitectura x64. En el .csprojarchivo:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release-ABC|AnyCPU'">
    <OutputPath>bin\Release-ABC</OutputPath>
    <PlatformTarget>x64</PlatformTarget>
</PropertyGroup>

Una falta PlatformTargetcausó este error.

Estuve obteniendo:

No se pudo cargar el archivo o ensamblado 'XXX-new-3.3.0.0' 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)

Fue porque cambié el nombre de la asamblea de XXX.dlla XXX-new-3.3.0.0.dll. Volver el nombre al original solucionó el error.

Es casi como si tuvieras que borrar tu computadora para deshacerte del viejo dll. Ya he intentado todo lo anterior y luego di el paso adicional de eliminar cada instancia del archivo .DLL que estaba en mi computadora y eliminar todas las referencias de la aplicación. Sin embargo, todavía se compila muy bien y cuando se ejecuta hace referencia a las funciones dll muy bien. Estoy empezando a preguntarme si lo está haciendo referencia desde una unidad de red en algún momento.

Recibí el mismo mensaje al cambiar entre dos versiones de una aplicación que hacía referencia a diferentes versiones de la misma DLL. Aunque estaba probando en diferentes carpetas, copié accidentalmente la versión más nueva sobre la versión anterior.

Entonces, lo primero que debe verificar es la versión de la DLL a la que se hace referencia en la carpeta de la aplicación. Por si acaso.

Quizás esto ayude o quizás no. Limpié mis versiones de depuración y lanzamiento, luego cambié el nombre de la carpeta OBJ. Esto finalmente me hizo sentir bien. Los pasos anteriores eran básicamente eliminar referencias de proyectos y agregarlas nuevamente a las propiedades del proyecto.

En My Visual Studio 2015, me aseguré de que la lista de rutas de referencia del proyecto de Visual Studio está vacía:

Esto es lo que funcionó para mí:

Estaba usando la Microsoft.IdentityModel.Clients.ActiveDirectoryversión 3.19 en un proyecto de biblioteca de clases, pero solo tenía instalada la versión 2.22 en el proyecto de aplicación web ASP.NET real. La actualización a 3.19 en el proyecto de la aplicación web me superó el error.

En mi caso, tenía 3 proyectos, 1 proyecto principal y 2 subproyectos a los que hace referencia el proyecto principal. Así que actualicé el proyecto principal, dejando de lado el subproyecto. Ahí es donde estaba el conflicto. Después de actualizar todo mi proyecto, todo funcionó bien.

En VS2017, he probado toda la solución anterior pero nada funciona. Estamos usando Azure Devops para el control de versiones.

1. Desde el explorador de equipos> Explorador de control de código fuente

2. Selecciona el proyecto que te vuelve loco durante mucho tiempo

3. Haga clic derecho en la rama o solución> Avanzado> obtener versión específica

4. Luego, asegúrese de haber marcado la casilla de verificación de sobrescribir archivos según la captura de pantalla

En mi caso, elegí accidentalmente la versión incorrecta del paquete Telerik de nuget, que luego reemplazó cada paquete al que hice referencia con la versión incorrecta. Luego insertó una redirección de enlace a la versión incorrecta, de modo que incluso después de haber reemplazado todo con la versión correcta, todavía estaba buscando la versión incorrecta.