.Net escolhendo versão de montagem referenciada incorreta

141

Eu apenas copiei um projeto existente em uma máquina nova para começar a desenvolvê-la e tive um problema com a versão de um dos meus assemblies referenciados (uma DLL telerik por acaso).

O projeto originalmente referenciou uma versão mais antiga do assembly (vamos chamá-lo v1.0.0.0). Minha nova máquina possui a versão mais recente do assembly instalada, então pensei em atualizá-la (vamos chamar a nova versão v2.0.0.0).

Agora, aqui está o problema: se eu copiar a dll v1.0.0.0 antiga para a pasta do projeto e adicioná-la como referência, o site será iniciado sem problemas. Se eu excluir essa referência (e também excluir a DLL antiga do meu sistema) e adicionar a nova versão (v2.0.0.0), a página mostrará a seguinte exceção:

Não foi possível carregar o arquivo ou o conjunto 'XXXXXX, Versão = 1.0.0.0, Culture = neutral, PublicKeyToken = 121fae78165ba3d4' ou uma de suas dependências. A definição de manifesto da montagem localizada não corresponde à referência da montagem. (Exceção de HRESULT: 0x80131040)

Claramente, o código está procurando a versão desatualizada e não a encontra. Mas por que?

Procurei na pasta da solução esse número de versão e não consegui encontrar uma única referência. Verifiquei o texto do arquivo .csproj e verifiquei que a versão mostra corretamente a versão mais recente e o HintPath mostra corretamente o caminho para a nova DLL. Além disso, como eu não instalei a DLL antiga no sistema, ela não aparece no meu GAC (embora a v2.0.0.0 apareça como esperado).

Habilitei o visualizador de log de fusão a tentar descobrir por que ele está procurando essa versão antiga, mas sem sorte:

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.

Tudo o que diz é que começa procurando aquela assembléia antiga. Tentei encontrar uma solução on-line e vi essa pergunta SO semelhante , mas parece ser exatamente o oposto do meu problema. O programa desse questionador estava encontrando a DLL errada em vez da referenciada. Considerando que o meu problema é que o programa está procurando misteriosamente a DLL errada e não consegue encontrá-la quando a correta pode ser encontrada localmente na pasta bin e no GAC.

Por que o meu está procurando a versão antiga? Onde mais posso procurar para encontrar essa referência ruim?

Michael La Voie
fonte

Respostas:

151

Meu palpite é que outro assembly que você está usando está referenciando a dll antiga. Você está familiarizado com todas as outras referências de projeto em uso e alguma delas tem uma referência às dlls da Telerik?

Você pode colocar um redirecionamento de ligação no seu arquivo web.config assim?

<dependentAssembly>
 <assemblyIdentity name="Telerik" publicKeyToken="121fae78165ba3d4"/>
 <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>
Chris Conway
fonte
12
Eu tive todos os tipos de problemas semelhantes a este com versões diferentes carregando / não carregando. Outro truque que você pode tentar é excluir manualmente todos os arquivos da sua pasta C: /WINDOWS/Microsoft.NET/Framework/v4.0.30319/ Arquivos temporários do ASP.NET / root / 90233b18 / 10d54998. Às vezes, ao recompilar sites, o ASP.Net não limpa essa pasta devido a alguns bloqueios de arquivos e essas DLLs podem estar penduradas em referências antigas. Vale a pena tentar, eu sei que funcionou para mim no passado.
Chris Conway
1
Você resolveu um problema relacionado para mim - obrigado! Um formulário herdado no meu aplicativo C # não seria aberto no designer porque estava procurando uma versão antiga de uma referência. Acontece que outra referência foi criada originalmente ao fazer referência à versão antiga da referência do problema.
Sam Skuce
2
Se você está vagando pela sintaxe: msdn.microsoft.com/en-us/library/0ash1ksb.aspx
Junior Mayhé 04/04/12
1
Obrigado Chris! Você resolveu meu problema aqui: stackoverflow.com/q/11490177/7850
Shaul Behr
3
Você também pode procurar em seu App.config ou web.config e ver se as <dependentAssembly>entradas existentes estão causando o problema.
Roy Tinker
24

Estou com Chris Conway neste (votou nele). O problema é que você está fazendo referência a um dos conjuntos de telerik no seu projeto que faz referência a outro que não está lá.

Primeira coisa: eu não instalaria QUALQUER assembléia de fornecedor (ou seja, telerik) no GAC. O material da Telerik é compilado em apenas duas montagens (telerik.web.design e telerik.web.ui). Basta implantar aqueles com o aplicativo.

Segundo, em cada um dos seus arquivos .proj (como .csproj), haverá um <reference include..>que aponta para o arquivo Telerik.Web.UI. Normalmente contém um número de versão. Verifique se a montagem que você colocou na pasta bin corresponde a essa versão.

Terceiro, verifique se TODOS os seus projetos usam a montagem mais recente. Verifique também se eles estão pegando a montagem de um caminho local em vez do GAC. (Realmente não gosto do GAC. Isso não causou problemas em alguns projetos em que estive). Normalmente, temos uma pasta "Assemblies" que todos os projetos usam para referências de assemblies externos.

Quarto, o visual studio pesquisa automaticamente seu gac sempre que um projeto de site é carregado e redireciona novamente os locais de montagem se encontrar algo no gac. Não me lembro se isso é feito em projetos de aplicativos da web, mas não tenho problema há muito tempo com eles. Isso pode causar problemas semelhantes durante a implantação.

Quinto, você pode religar os números de versão para montagens no web.config. Na runtime/assemblybindingseção, você pode usar algo como o seguinte, que leva adiante todos os assemblies de telerik implantados em 2008 e aponta para uma versão muito específica:

  <dependentAssembly>
    <assemblyIdentity name="Telerik.Web.UI" publicKeyToken="121fae78165ba3d4" />
    <bindingRedirect oldVersion="2008.0.0.0-2020.0.0.0" newVersion="2010.02.0713.35" />
  </dependentAssembly>
Eu não
fonte
2
Eu quis dizer "sensação", que está me incomodando há meses :)
Michael La Voie
21

Tentei a maioria das respostas, mas ainda não consegui fazê-lo funcionar. Isso funcionou para mim:

clique com o botão direito do mouse na referência -> propriedades -> altere 'Versão específica' para false.

insira a descrição da imagem aqui

Espero que isto ajude.

RayLoveless
fonte
30
É isso que significa votar no +1.
xr280xr
7
Mas, às vezes, o simples voto positivo não resume suficientemente o quão feliz e aliviada a resposta o deixa - depois de passar horas e horas tentando consertar um problema idiota que nem deveria ser um problema, e você tenta pesquisar no Google de uma maneira diferente , encontre uma resposta diferente da que você tentou antes e boom! funciona agora! Depois de tudo isso, às vezes simplesmente pressionar o botão upvote não faz justiça a esse sentimento avassalador de, cara, você realmente me salvou dessa.
Michael Plautz
7

Experimentar:

  • limpando arquivos temporários do projeto
  • limpando arquivos de construção e obj
  • limpeza de versões antigas instaladas em C:\Users\USERNAME\.nuget\packages\

Isso funcionou para mim.

delira
fonte
1
Limpar o diretório C: \ Users \ USERNAME \ .nuget \ packages \ era o que estava faltando. Muito obrigado!
Herdo
para a versão antiga limpa do nuget, no computador baseado no Windows, ckuck Inicie e pesquise por "executar"> copie e cole "% userprofile% \. nuget \ packages" - isso abrirá a pasta versões do
nuget
3
  1. Vá para C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG
  2. Encontre o arquivo machine.config
  3. aberto no bloco de notas
  4. encontrar conflito dll
  5. Remova isso e salve.

montagens de compilação

addassembly = dllName, versão = 1.0.0000.0000 Cultura = neutra, PublicKeyToken = "QWEWQERWETERY"

compilação de montagens

funciona para mim.

Reynan de la Cruz
fonte
2
Eu também descobri este pesadelo - mesmo se você remover a montagem do GAC deixa referências versão errada em "C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG \ machine.config"
Evalds Urtans
3

Esta não é uma resposta clara sobre o porquê, mas tivemos esse problema, eis as nossas circunstâncias e o que o resolveu:

Dev 1:

A solução contém o Projeto A que faz referência a um pacote NuGet e um projeto MVC que faz referência ao Projeto A. Habilitou a Restauração do pacote NuGet e atualizou o pacote NuGet. Ocorreu um erro de tempo de execução reclamando que a lib do NuGet não pode ser encontrada - mas o erro é procurar a versão mais antiga e não atualizada. Solução (e isso é ridículo): defina um ponto de interrupção na primeira linha de código no projeto MVC que chama Projeto A. Entre com F11. Resolvido - nunca mais tive um problema.

Dev 2:

A mesma solução e projetos, mas o ponto de interrupção do conjunto mágico e a solução passo a passo não funcionam. Procurou em toda parte redirecionamentos de versão ou outras referências incorretas a esse pacote Nuget, removeu o pacote e o reinstalou, limpou bin, obj, Asp.Net Temp, nada resolveu. Finalmente, renomeado Projeto A, executou o projeto MVC - corrigido. Renomeou-o de volta ao seu nome original, permaneceu fixo.

Eu não tenho nenhuma explicação para o porquê disso funcionou, mas isso nos tirou de uma briga séria.

Chris Moschini
fonte
2

Você tem algum outro projeto nessa solução? (Pode haver outro projeto fazendo referência a uma versão antiga) Normalmente, no VS, a dependência da dll abrange todos os projetos na solução.

AspNetDev
fonte
Nenhum outro projeto na solução e nenhuma outra DLL referenciada que faça referência ao telerik. Eu só estou fazendo referência MS DLLs ala Sistema *.
Michael La Voie
2

Meu problema era que os assemblies antigos estavam na pasta _bin_deployableAssemblies no aplicativo da Web. Isso significava que as assembléias antigas estavam substituindo as assembléias do GAC ao criar o projeto.

Warrickh
fonte
2

No caso, salva alguém mais 3 horas ... meu caso foi um pouco diferente. Meu código usou o DevExpress v11.1 v11.1.4.0. Eu tinha tudo referenciado corretamente no meu código. Mas o criador de perfil de memória .net instalou o DevExpress v11.1 v11.1.12.0 no GAC. Na verdade, não foram os componentes que referenciei, mas os que eles referenciaram internamente que falharam. Por mais que eu tente, o GAC é sempre verificado primeiro. Ele compilou e funcionou bem, mas eu não conseguia visualizar o designer de formulários de vitória e o rastreamento da pilha não ajudou em nada. Finalmente desinstalou o perfilador de memória .net e tudo foi restaurado.

Riquinho
fonte
2

Eu tive um problema semelhante e precisei excluir tudo das pastas bin e obj e reconstruí-lo para solucionar o problema. Espero que isto ajude.

Edd
fonte
1

Se você estiver enfrentando esse problema ao testar e / ou depurar o aplicativo do ambiente Visual Studio (ASP.NET Development Server), é necessário excluir todos os arquivos temporários na pasta do site de desenvolvimento. Para saber onde está essa pasta, procure o ícone do ASP.NET Development Server no ícone da bandeja do Windows (ele deve ter um título como este: ASP.NET Development Server - Porta ####), clique com o botão direito do mouse no ícone e selecione Mostrar Detalhes; Em seguida, o campo Caminho físico informará qual é a pasta temporária; todos os itens devem ser excluídos para resolver o problema. Crie e execute novamente o site e o problema deve ser resolvido (novamente, resolvido para o ambiente de desenvolvimento).

Gedeon
fonte
1

Eu tive o mesmo problema com assemblies diferentes referenciando versões diferentes do Newtonsoft.json. A solução que funcionou para mim foi executar o pacote de atualização no Nuget Package Manager Console.

brando
fonte
1

Este erro foi um pouco enganador - eu estava carregando algumas DLLs que exigiam que a arquitetura x64 fosse especificada. No .csprojarquivo:

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

Uma falta PlatformTargetcausou esse erro.

Ben
fonte
1

Eu estava conseguindo:

Não foi possível carregar o arquivo ou assembly 'XXX-new-3.3.0.0' ou uma de suas dependências. A definição de manifesto da montagem localizada não corresponde à referência da montagem. (Exceção de HRESULT: 0x80131040)

Foi porque mudei o nome da montagem de XXX.dllpara XXX-new-3.3.0.0.dll. A reversão do nome para o original corrigiu o erro.

mimo
fonte
Sim - incluiu uma versão no nome em nossa biblioteca de montagem comum para evitar problemas de nomeação no controle de origem. Alterou o nome de volta e atualizou manualmente os caminhos de referência / dica e tudo funcionou.
Mathew Paxinos
0

É quase como se você tivesse que acabar com o seu computador para se livrar da dll antiga. Eu já tentei de tudo acima e depois dei o passo extra de excluir todas as instâncias do arquivo .DLL que estava no meu computador e remover todas as referências do aplicativo. No entanto, ele ainda compila muito bem e, quando executado, faz referência às funções da dll. Estou começando a me perguntar se ele está fazendo referência a partir de uma unidade de rede em algum lugar.

SQLKing
fonte
0

Eu tive a mesma mensagem ao alternar entre duas versões de um aplicativo que referenciava versões diferentes da mesma DLL. Embora eu estivesse testando em pastas diferentes, copiei acidentalmente a versão mais recente sobre a versão mais antiga.

Portanto, a primeira coisa a verificar é a versão da DLL referenciada na pasta do aplicativo. Apenas no caso de.

Carl Onager
fonte
0

Talvez isso ajude ou talvez não. Limpei minhas versões de depuração e lançamento e renomeei a pasta OBJ. Isso finalmente me emocionou. As etapas anteriores foram basicamente remover o projeto de referências e adicioná-las novamente nas propriedades do projeto.

Tim
fonte
0

No My Visual Studio 2015, assegurei que a Lista de caminhos de referência do projeto ofensivo do Visual Studio estivesse vazia:

insira a descrição da imagem aqui

crazyTech
fonte
Você postou exatamente a mesma resposta para duas perguntas diferentes?
AK47 28/02
0

Isto é o que funcionou para mim:

Eu estava usando a Microsoft.IdentityModel.Clients.ActiveDirectoryversão 3.19 em um projeto de biblioteca de classes, mas só tinha a versão 2.22 instalada no projeto real do aplicativo Web do ASP.NET. A atualização para a versão 3.19 no projeto de aplicativo da web levou-me ao erro.

aBlaze
fonte
0

No meu caso, eu tinha 3 projetos, 1 projeto principal e 2 subprojetos referenciados pelo projeto principal. Então atualizei o projeto principal, deixando de fora o subprojeto. Foi onde o conflito estava. Depois que eu atualizei todo o meu projeto, tudo funcionou bem.

Siphamandla Hero Ngwenya
fonte
0

No VS2017, tentei toda a solução acima, mas nada funciona. Estamos usando os devops do Azure para controle de versão.

  1. No explorador de equipes> Source Control Explorer

insira a descrição da imagem aqui

  1. Selecione o projeto que o deixa louco por um longo tempo

  2. Clique com o botão direito do mouse na ramificação ou solução> Avançado> obter versão específica

insira a descrição da imagem aqui

  1. Em seguida, verifique se você marcou a caixa de seleção Substituir arquivos conforme a captura de tela

insira a descrição da imagem aqui

Ragavan Rajan
fonte
0

No meu caso, escolhi acidentalmente a versão incorreta do pacote Telerik do nuget, que substituiu todos os pacotes referenciados pela versão incorreta. Em seguida, ele inseriu um redirecionamento de ligação para a versão incorreta, para que, mesmo depois de substituir tudo pela versão correta, ele ainda estivesse procurando a versão incorreta.

Karl Dembeck
fonte