Error CS1705: "que tiene una versión superior al ensamblado al que se hace referencia"

He estado investigando esto por un tiempo y no lo he resuelto. Recibo el siguiente mensaje de error:

Compiler Error Message: CS1705: Assembly 'My.Model, Version=1.1.4422.23773, Culture=neutral, 
PublicKeyToken=bfde95ba233094b2' uses 
'Common, Version=3.3.4273.24368, Culture=neutral, PublicKeyToken=bfde95ba233094b2' 
which has a higher version than referenced assembly
'Common, Version=3.3.4269.17112, Culture=neutral, PublicKeyToken=bfde95ba233094b2'

c:\WINDOWS\assembly\GAC_MSIL\Common\3.3.4269.17112__bfde95ba233094b2\Common.dll: 
(Location of symbol related to previous error)

El servidor web está ejecutando Server 2003. Fui a c: \ windows \ assembly y de hecho noté que había 3 versiones de Common.dll en la lista. La versión más alta de la lista fue 3.3.4269.17112

Copié el dll con la versión: 3.3.4273.24368 en el directorio de ensamblaje. Luego recompillé y volví a implementar mi código (probablemente exagerado, pero bueno). Cuando abrí mi navegador en una nueva sesión y fui a la URL del sitio nuevamente, todavía recibí el mismo mensaje.

Puedo usar el explorador de Windows y verificar que Common.dll con una versión superior ahora también esté en la lista.

¿Qué más puedo investigar para resolver este problema? No quiero cambiar la referencia en mi ensamblado para que apunte a la versión anterior.

3 ideas para que pruebes:

1. Asegúrese de que todas sus DLL estén compiladas con la misma versión de Common.
2. Compruebe que tiene referencias de proyectos en su solución en lugar de referencias de archivos.
3. Utilice redirecciones vinculantes en su web.config. ( Versión originalmente vinculada en wayback machine )

Tuve este error porque "Rebuild" no estaba realmente reconstruyendo.

Solución: cierre Visual Studio, vaya y elimine la carpeta bin, luego reconstruya, podría funcionar mejor.

Además, a veces Visual Studio miente sobre las referencias, así que verifique HintPathen sus .csprojarchivos.

Si está utilizando NuGet, vale la pena ir a 'Administrar paquetes NuGet para la solución' , encontrar el paquete que está causando problemas y actualizar. Luego, debería actualizar todos los paquetes a la última versión y resolver el problema.

Vale la pena intentarlo, ya que es rápido y fácil.

Mi problema fue que tenía 2 proyectos que hacían referencia a 2 copias diferentes del mismo dll que tenían diferentes versiones. Lo arreglé eliminando ambos y asegurándome de que estaban haciendo referencia al mismo archivo dll.

Una posible causa es que el segundo ensamblado esté instalado en GAC mientras que el primer ensamblado, con un número de versión más alto, se agrega a las Referencias del proyecto. Para verificar esto, haga doble clic en el ensamblaje en las referencias del proyecto y verifique si hay otro ensamblaje con el mismo nombre en el Explorador de objetos.

Si ese es el caso, use la utilidad gacutil.exe para desinstalar el segundo ensamblado del GAC. Por ejemplo, si se trata de ensamblados de 64 bits:

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\gacutil.exe -u <assembly_name>

Vaya a Referencia y agregue una nueva referencia de su archivo dll que está causando el problema y asegúrese de que todas sus dll estén compiladas con la misma versión. Funciona para mí, espero que también funcione para ti.

Mi equipo acaba de encontrar este problema en nuestro entorno de construcción. El problema se debió a una diferencia en el elemento <HintPath> del archivo .csproj.

Nuestro ensamblado común tenía una ruta relativa correcta al directorio que contiene nuestros ensamblados de referencia. El ensamblado dependiente tenía una ruta de una estructura de directorio anterior. La solución se compiló con éxito en máquinas de desarrollo cuando el GAC resolvió la referencia del dependiente a la versión correcta instalada en C: \ Archivos de programa. El entorno de compilación tenía una instalación heredada del ensamblaje (aunque no debería haber tenido ninguna) a la que recurrió y, por lo tanto, el error. La actualización de <HintPath> en un editor de texto corrigió el problema.

El problema se ve si los paquetes nuget varían en varios proyectos dentro de la solución.

Puede solucionar este problema actualizando los paquetes nuget a una versión común con todos los PROYECTOS en la SOLUCIÓN

Tuvo un problema similar. Mi problema fue que tenía varios proyectos dentro de la misma solución y cada uno hacía referencia a una versión específica de una DLL pero versiones diferentes. La solución fue establecer "Versión específica" en falso en todas las propiedades de todas las referencias.

Sé que esto se preguntó hace bastante tiempo, después de probar algunos de los pasos anteriores. Lo que me ayudó fueron los siguientes pasos y este artículo .

Localicé la referencia y cambié PublicKeyToken del que se hace referencia al anterior.

Espero que esto también ayude.

Tuve el mismo error. Arreglé el error después de instalarlo Microsoft.AspNetCore.ALLen el proyecto de prueba.

Carpeta de colección de DLL hecho a mano
Si la solución tiene una carpeta de basura para dll archivos de diferentes bibliotecas
lib, source, libs, etc.
Usted puede obtener este problema si va a abrir su solución (por un tiempo abetos) en Visual Studio. Y la carpeta de recopilación de su dll se pierde de alguna manera o se pierde un archivo dll concreto.

Visual Studio intentará silenciosamente sustituir la referencia de dll por algo por sí solo. Si VS tiene éxito, se mantendrá una nueva referencia para su solución local. No para otros clones / pagos.

Es decir <HintPath>, se ignorará y su archivo de proyecto (.csproj) no se cambiará.
Como un ejemplo de mi

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\..\..\lib\DocumentFormat.OpenXml.dll</HintPath>
</Reference>

Se DocumentFormat.OpenXmlhará referencia a él desde C:\Program Files (x86)\Open XML SDK\V2.5\libno desde una solution\..\libcarpeta.

solución rápida

• comprobar y restaurar la carpeta de recogida de su dll
• desde el Explorador de soluciones, descargue el proyecto y luego vuelva a cargar el proyecto .

La solución alternativa correcta es migrar al administrador de paquetes NuGet.

para SharePoint, asegúrese de que en su carpeta raíz no tenga una carpeta "bin" con sus archivos DLL, si es así, elimínela. (y cambie "Copiar local" a falso en VS).

Las referencias en un proyecto de sitio web se almacenan en su archivo web.config. Actualice la referencia allí para corregir el error.

Pasé algún tiempo mirando todas las referencias en mi solución antes de darme cuenta de que me había olvidado de las referencias en el archivo web.config.

Tuve el mismo problema con UnitTestingProject, donde en MainProject estaba usando "System.Web.Mvc, Version = 3.0.0.0" y en UnitTestingProject estaba usando "System.Web.Mvc, Version = 3.0.0.1"

Cambie lo siguiente en el <Reference Include="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> <HintPath>..\packages\Microsoft.AspNet.Mvc.3.0.50813.1\lib\net40\System.Web.Mvc.dll</HintPath> </Reference>

Obtuve esto después de agregar Episerver Find a nuestro sitio e instalar el paquete NuGet correspondiente para Episerver Find.

La solución fue fácil: actualice también todos los complementos relacionados con Episerver (incluso si parecen no estar relacionados: CMS, CMS.TinyMCE, CMS.UI, etc.)

Después de actualizar todos los posibles complementos de Episerver y volver a compilar, el error desapareció.

En mi escenario, edité el archivo .csproj para mi aplicación dotnetCore. Noté que la etiqueta TargetFramework tenía un valor de netcoreapp2.1 y la etiqueta RuntimeFrameworkVersion un valor de 2.0.0 . Así que cambié RuntimeFrameworkVersion a 2.1.0 , , reinicié VS y reconstruí y luego resolvió los errores.

Espero que esto te ayudará ...

Buena suerte,

Sugeshan

En su proyecto busque referencias System.Web.Mvc verifique la versión.

Después de que haga clic derecho referencias -> asambleas y la búsqueda System.Web.Mvc y configuración de la misma.

El problema provoca que las diferentes versiones de estos ensamblajes .

Editar: luego seleccione administrar paquetes NuGet e instale las actualizaciones (si tiene varios proyectos, instale actualizaciones también).

La actualización importante es Microsoft.AspNet.Mvc y Microsoft.Net.Compilers ¡ No lo olvides!

En nuestro equipo estábamos trabajando en diferentes computadoras con git. Alguien actualizó un dlly yo no lo tenía. Acabo de actualizar las referencias de mis dependencias y el problema se resolvió.

Tuve un problema similar, había creado una DLL, es decir, A.dll, que hacía referencia a otra DLL, es decir, B.dll.

Creé una aplicación C.exe y hice referencia a las DLL A.dll y B.dll.

Solución: al eliminar la referencia de B.dll de c.exe, pude solucionar el problema.

Espero que esto ayude.