Error CS1705: "que tiene una versión más alta que el ensamblado al que se hace referencia"

He estado investigando esto por un tiempo y no lo he resuelto. Me sale el siguiente mensaje de error:Error CS1705: "que tiene una versión más alta que el ensamblado al que se hace referencia"

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 se está ejecutando Server 2003. Fui a C: \ Windows \ assembly y lo hizo en el aviso de que había 3 versiones de Common.dll enumerados. La versión más alta de la lista era 3.3.4269.17112

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

Puedo usar el explorador de Windows y verificar que Common.dll versión más alta ahora también está en la lista.

¿Qué más puedo ver para resolver este problema? No quiero cambiar la referencia en mi conjunto para apuntar a la versión anterior.

Fuente

2012-02-09 jbizzle

Crazy '*. *' Números de versión. Reconstruye todo, solo forma de estar seguro. –

3 ideas para que usted pueda probar:

asegurarse de que todos los archivos DLL se compilan en contra de la misma versión del común.
Compruebe que tiene referencias de proyectos en su solución en lugar de referencias de archivos.
Uso binding redirections en su web.config

Fuente

2012-02-09 22:59:25

el enlace a la redirección de enlace ya no funciona ... – moudrick

(Además de las ideas Jakub')

tuve este error porque "Reconstruir" no era realmente la reconstrucción.
Cerrar Visual Studio, realmente ir y eliminar la carpeta bin, luego reconstruir, podría funcionar mejor.

Además, a veces Visual Studio miente acerca de las referencias, por lo que verifique el HintPath en sus archivos .csproj.

Fuente

2013-02-12 06:35:03

Éste salvó mi tocino. Correr local estaba bien, pero publiqué un cambio y las cosas se volvieron locas. Eliminar el contenido de la carpeta bin en línea obligó a las cosas a volver a sincronizarse. ¡Gracias! – pStan

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

Fuente

2013-03-19 04:46:41 Rahul

Mi problema es que tengo 2 proyectos que hacen referencia a 2 copias diferentes del mismo dll que tienen versiones diferentes. Lo solucioné eliminándolos y asegurándome de que estaban haciendo referencia al mismo archivo dll.

Fuente

2013-05-22 04:31:37

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

Nuestro conjunto común tenía una ruta relativa correcta al directorio que contiene nuestros conjuntos de referencia. El ensamblado dependiente tenía una ruta desde 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 ensamblado (aunque no debería haber tenido ninguno) al que recurrió y, por lo tanto, el error. La actualización de <HintPath> en un editor de texto corrigió el problema.

Fuente

2013-07-29 18:49:37

-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 las DLL a las que se hace referencia 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.

Fuente

2013-09-12 18:39:40 Yahya

Una posible causa es que el segundo conjunto se instala en GAC, mientras que el primer conjunto, con un número de versión superior, se agrega a las referencias del proyecto. Para verificar esto, haga doble clic en el conjunto en las referencias del proyecto y verifique si hay otro ensamblado con el mismo nombre en el Examinador de objetos.

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

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

Fuente

2013-10-09 18:10:00 jgong

Dos años después y su sugerencia funcionó a las mil maravillas. Ver las referencias en el buscador de objetos lo ordenó. – ceebreenk

Si está utilizando NuGet vale la pena ir a 'administrar paquetes NuGet Para la solución', para encontrar el paquete que está causando problemas y golpear actualización. Debería llevar todos los paquetes a la última versión y resolver el problema.

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

Fuente

2014-03-13 15:45:37 CountZero

Esto lo resolvió para mí, gracias. Sin embargo, mi situación era ligeramente diferente: no aparecía en las actualizaciones, así que tuve que ir a la instalación 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 salvaste una tediosa edición de 'csproj'! – rtpHarry

Asegúrese de actualizar los paquetes NuGet en el nivel de solución en lugar del nivel del proyecto. – Jess

Esta ciertamente debería ser la respuesta aceptada por todos los medios, no lo leí pero intenté en mi solución involuntariamente, lo cual funcionó a las mil maravillas. – baymax

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

Fuente

2014-04-02 10:31:13 gnuchu

Sé que esto fue preguntado hace bastante tiempo, después de probar algunos de los pasos anteriores. Lo que me ayudó fueron los siguientes pasos y this article.

Localicé la referencia y cambié el PublicKeyToken del que está referenciado al anterior.

Espero que esto ayude también.

Fuente

2015-05-18 11:28:35 Haris

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

Después de que haga clic derecho referances -> asambleas y System.Web.Mvc buscar y configuración ella.

El problema provoca las diferentes versiones de estos conjuntos .

Editar: que la selección gestionar paquetes NuGet e instalar las actualizaciones (si tiene varios proyectos de instalación de actualizaciones a ellos también.)

Actualización importante es Microsoft.AspNet.Mvc y Microsoft.Net.Compilers ¡no lo olvides!

Fuente

2016-02-29 09:12:33 Hadnazzar

carpeta de colección de hecho a mano DLL
Si la solución tiene una carpeta de basura para dll archivos de diferentes bibliotecas
lib, source, libs, etc.
Puede obtener este problema si abre su solución (por primera vez) en Visual Studio. Y la carpeta de colecció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 solo. Si VS tendrá éxito, entonces una nueva referencia será persistente para su solución local. No para otros clones/cajas.

I.e. su <HintPath> se ignorará y el archivo de proyecto (.csproj) no se modificará.
Como ejemplo de mí

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

El DocumentFormat.OpenXml se hará referencia a partir C:\Program Files (x86)\Open XML SDK\V2.5\lib no de una carpeta solution\..\lib.

Solución rápida

control y la reposición que DLL recoger carpeta
desde el Explorador de soluciones hacen Unload Proyecto, a continuación, cargar proyecto .

La solución correcta es migrar a NuGet package manager.

Fuente

2017-02-02 11:56:39 it3xl

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

Fuente

2017-08-28 12:23:10 bresleveloper

Error CS1705: "que tiene una versión más alta que el ensamblado al que se hace referencia"

Respuesta

Cuestiones relacionadas