Erro CS1705: “que tem uma versão superior ao conjunto referenciado”

109

Estou investigando isso há um tempo e ainda não resolvi. Eu recebi a seguinte mensagem de erro:

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)

O servidor da web está executando o Server 2003. Eu fui para c: \ windows \ assembly e de fato notei que havia 3 versões de Common.dll listadas. A versão mais alta listada foi 3.3.4269.17112

Copiei a dll com a versão: 3.3.4273.24368 para o diretório de montagem. Eu então recompilei e reimplantei meu código (provavelmente um exagero, mas tudo bem). Quando abri meu navegador em uma nova sessão e fui para a URL do site novamente, ainda recebi a mesma mensagem.

Posso usar o Windows Explorer e verificar se o Common.dll com versão superior também está listado.

O que mais posso fazer para resolver esse problema? Não quero alterar a referência em minha montagem para apontar para a versão mais antiga.

.net web-deployment Jbizzle
fonte
2
*.*Números de versão loucos . Reconstrua tudo, única maneira de ter certeza.
Hans Passant de

Respostas:

68

Eu tive este erro porque "Reconstruir" não era realmente reconstruir.

Solução: Feche o Visual Studio, realmente exclua a pasta bin e, em seguida, reconstrua, pode funcionar melhor.

Além disso, às vezes o Visual Studio mente sobre referências, portanto, verifique os HintPathem seus .csprojarquivos.

Nicolas Raoul
fonte
2
Este salvou meu bacon. Administrar localmente estava bem, mas publiquei uma mudança e as coisas ficaram malucas. A exclusão do conteúdo da pasta bin online forçou as coisas a voltarem a sincronizar. Obrigado!
pStan
40

Se você estiver usando o NuGet, vale a pena ir em 'Gerenciar pacotes NuGet para solução' , localizar o pacote que está causando problemas e clicar em atualizar. Em seguida, ele deve trazer todos os pacotes para a versão mais recente e resolver o problema.

Vale a pena tentar, pois é rápido e fácil.

CountZero
fonte
2
Isso resolveu para mim, obrigado. Minha situação era um pouco diferente: não estava listado nas atualizações, então tive que ir para instalado e havia uma janela que mostrava a versão do pacote por projeto. Eu estava atualizando alguns módulos antigos para uma nova versão de um cms, então tive que ir para os pacotes com problemas, selecioná-los e clicar em instalar. Pode ter sido porque o cms acabou de mudar para usar nuget, mas você me poupou de muitas csprojedições tediosas !
rtpHarry
3
Certifique-se de atualizar os pacotes NuGet no nível da solução, e não no nível do projeto.
Jess
2
Essa certamente deveria ser a resposta aceita por todos os meios, eu não li isso, mas tentei minha solução sem querer, que funcionou como um encanto.
baymax
30

Meu problema era que eu tinha 2 projetos referenciando 2 cópias diferentes da mesma dll que tinham versões diferentes. Eu consertei removendo os dois e verificando se eles estavam fazendo referência ao mesmo arquivo DLL.

Andrew Ngo
fonte
13

Uma possível causa é que o segundo assembly é instalado no GAC enquanto o primeiro assembly, com um número de versão superior, é adicionado às referências do projeto. Para verificar isso, clique duas vezes na montagem nas referências do projeto e verifique se há outra montagem com o mesmo nome no Pesquisador de objetos.

Se for esse o caso, use o utilitário gacutil.exe para desinstalar o segundo assembly do GAC. Por exemplo, se forem conjuntos de 64 bits:

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\gacutil.exe -u <assembly_name>
jgong
fonte
Dois anos depois, sua sugestão funcionou perfeitamente. A visualização das referências no Pesquisador de objetos classificou-o.
ceebreenk
3

Vá para Referência e adicione uma nova referência do arquivo dll que está causando o problema e certifique-se de que todas as dlls sejam compiladas com a mesma versão. Funciona para mim, espero que funcione para você também.

Rahul
fonte
2

Minha equipe acabou de encontrar esse problema em nosso ambiente de construção. O problema era devido a uma diferença no elemento <HintPath> do arquivo .csproj.

Nosso assembly comum tinha um caminho relativo correto para o diretório que contém nossos assemblies de referência. O assembly dependente tinha um caminho de uma estrutura de diretório anterior. A solução foi compilada com sucesso em máquinas de desenvolvimento, pois o GAC resolveu a referência do dependente para a versão correta instalada em C: \ Arquivos de programas. O ambiente de construção tinha uma instalação legada do assembly (embora não devesse ter nenhuma) para a qual ele retrocedeu e, portanto, o erro. Atualizar o <HintPath> em um editor de texto corrigiu o problema.

Russell Speight
fonte
2

O problema é visto se os pacotes nuget variam em vários projetos dentro da solução.

Você pode corrigir isso atualizando os pacotes nuget para uma versão comum com todos os PROJETOS na SOLUÇÃO

Krishna Prasad S
fonte
1

Teve um problema semelhante. Meu problema era que eu tinha vários projetos na mesma solução, cada um referenciando uma versão específica de uma DLL, mas com versões diferentes. A solução foi definir 'Versão específica' como falsa em todas as propriedades de todas as referências.

gnuchu
fonte
1

Sei que isso foi perguntado há algum tempo, depois de tentar algumas das etapas acima. O que me ajudou foram as etapas a seguir e este artigo .

Eu localizei a referência e alterei o PublicKeyToken daquele que está sendo referenciado para o mais antigo.

Espero que isso ajude também.

atormentar
fonte
1

Eu tive o mesmo erro. Corrigi o erro depois de instalar Microsoft.AspNetCore.ALLno projeto de teste.

Haktan Enes Biçer
fonte
0

Pasta de coleção de dll Handmade
Se você solução tem uma pasta de lixo para dll-arquivos de diferentes bibliotecas
lib, source, libs, etc.
Você pode obter este problema se você vai abrir a sua solução (por um tempo abetos) no Visual Studio. E a pasta de coleta de sua dll é perdida de alguma forma ou um arquivo dll concreto é perdido.

O Visual Studio tentará silenciosamente substituir a referência da dll por algo por conta própria. Se o VS for bem-sucedido, uma nova referência será persistente para sua solução local. Não para outros clones / checkouts.

Ou seja, seu <HintPath>arquivo será ignorado e seu arquivo de projeto (.csproj) não será alterado.
Como um exemplo de mim

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

O DocumentFormat.OpenXmlserá referenciado de C:\Program Files (x86)\Open XML SDK\V2.5\libnão de uma solution\..\libpasta.

Solução alternativa rápida

  • verifique e restaure a pasta de coleta de dll
  • no Solution Explorer, faça Unload Project e , em seguida, Reload Project .

A solução alternativa certa é migrar para o gerenciador de pacotes NuGet.

it3xl
fonte
0

para o SharePoint, certifique-se de que em sua pasta raiz você não tenha uma pasta "bin" com suas DLLs, em caso afirmativo, apenas exclua-a. (e altere "Copiar local" para falso no VS).

Bresleveloper
fonte
0

As referências em um projeto de site são armazenadas em seu arquivo web.config. Atualize a referência para corrigir o erro.

Passei algum tempo examinando todas as referências em minha solução antes de perceber que tinha esquecido as referências no arquivo web.config.


fonte
0

Eu tive o mesmo problema com UnitTestingProject, onde no MainProject eu estava usando "System.Web.Mvc, Version = 3.0.0.0" e em UnitTestingProject eu estava usando "System.Web.Mvc, Version = 3.0.0.1"

Altere o seguinte no <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
fonte
0

Consegui isso depois de adicionar Episerver Find ao nosso site e instalar o pacote NuGet correspondente para Episerver Find.

A correção foi fácil: atualize todos os complementos relacionados ao Episerver também (mesmo que pareçam não relacionados: CMS, CMS.TinyMCE, CMS.UI, etc.)

Depois de atualizar todos os add-ons Episerver possíveis e recompilar, o erro foi embora.

webDevAndEverythingElse
fonte
0

Em meu cenário, editei o arquivo .csproj para meu aplicativo dotnetCore. Percebi que a tag TargetFramework tinha um valor de netcoreapp2.1 e a tag RuntimeFrameworkVersion um valor de 2.0.0 . Então eu mudei o RuntimeFrameworkVersion para 2.1.0 , salvei, reiniciei o VS e reconstruí e então resolvi os erros.

Espero que isso ajude você ...

Boa sorte,

Sugeshan

Sugeshan Govindsamy
fonte
-1

Em seu projeto encontre referências System.Web.Mvc verifique a versão.

Depois disso, clique com o botão direito em referências -> assemblies e pesquise system.web.mvc e configure -o.

O problema causa as diferentes versões desses assemblies .

Editar: em seguida, selecione gerenciar pacotes NuGet e instalar as atualizações (se você tiver vários projetos, instale atualizações neles também).

Atualização importante é Microsoft.AspNet.Mvc e Microsoft.Net.Compilers , não se esqueça disso!

Hadnazzar
fonte
-1

Em nossa equipe, estávamos trabalhando em diferentes computadores com o git. Alguém atualizou um dlle eu não o tinha. Acabei de atualizar minhas referências de dependências e o problema foi resolvido.

Masoud Darvishian
fonte
-3

Tive um problema semelhante, criei uma DLL, ou seja, A.dll, que referenciava outra DLL, ou seja, B.dll.

Criei um aplicativo C.exe e referenciei as DLLs A.dll e B.dll.

Solução - Ao remover a referência de B.dll de c.exe, consegui corrigir o problema.

Espero que isto ajude.

Yahya
fonte