.Net escolhendo versão de montagem referenciada incorreta

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?

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>

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>

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.

Espero que isto ajude.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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

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.

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.

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

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

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

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

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.