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

109

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.

.net web-deployment jbizzle
fuente
2
*.*Números de versión locos . Reconstruye todo, única forma de estar seguro.
Hans Passant

Respuestas:

68

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.

Nicolas Raoul
fuente
2
Este me salvó el tocino. Ejecutar localmente estaba bien, pero publiqué un cambio y las cosas se volvieron locas. Eliminar el contenido de la carpeta bin en línea obligó a que las cosas se volvieran a sincronizar. ¡Gracias!
pStan
40

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.

CountZero
fuente
2
Esto me solucionó, gracias. Sin embargo, mi situación era ligeramente diferente: no estaba en la lista de actualizaciones, así que tuve que ir a instalar y había una ventana que mostraba la versión del paquete por proyecto. Estaba actualizando algunos módulos antiguos a una nueva versión de un cms, así que tuve que ir a los paquetes problemáticos, seleccionarlos y hacer clic en instalar. ¡Podría haber sido porque el cms acababa de cambiar para usar nuget, pero me ahorraste muchas csprojediciones tediosas !
rtpHarry
3
Asegúrese de actualizar los paquetes de NuGet a nivel de solución en lugar de a nivel de proyecto.
Jess
2
Esta ciertamente debería ser la respuesta aceptada por todos los medios, no leí esto, pero probé mi solución sin querer, lo que funcionó como un encanto.
baymax
30

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.

Andrew Ngo
fuente
13

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>
jgong
fuente
Dos años más tarde y tu sugerencia funcionó a las mil maravillas. Ver las referencias en el Explorador de objetos lo ordenó.
ceebreenk
3

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.

Rahul
fuente
2

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.

Russell Speight
fuente
2

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

Krishna Prasad S
fuente
1

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.

gnuchu
fuente
1

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.

Harry
fuente
1

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

Haktan Enes Biçer
fuente
0

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.

it3xl
fuente
0

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

bresleveloper
fuente
0

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.


fuente
0

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>

Buminda
fuente
0

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

webDevAndEverythingElse
fuente
0

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

Sugeshan Govindsamy
fuente
-1

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!

Hadnazzar
fuente
-1

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

Masoud Darvishian
fuente
-3

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.

Yahya
fuente