A definição de manifesto da montagem localizada não corresponde à referência de montagem

Estou tentando executar alguns testes de unidade em um aplicativo Windows Forms C # (Visual Studio 2005) e recebo o seguinte erro:

System.IO.FileLoadException: não foi possível carregar o arquivo ou assembly 'Utility, Versão = 1.2.0.200, Culture = neutral, PublicKeyToken = 764d581291d764f7' ou uma de suas dependências. A definição do manifesto da montagem localizada não corresponde à referência da montagem. (Exceção de HRESULT: 0x80131040) **

em x.Foo.FooGO ()

em x.Foo.Foo2 (String groupName_) em Foo.cs: linha 123

em x.Foo.UnitTests.FooTests.TestFoo () em FooTests.cs: linha 98 **

System.IO.FileLoadException: não foi possível carregar o arquivo ou assembly 'Utility, Versão = 1.2.0.203, Culture = neutral, PublicKeyToken = 764d581291d764f7' ou uma de suas dependências. A definição do manifesto da montagem localizada não corresponde à referência da montagem. (Exceção de HRESULT: 0x80131040)

Olho nas minhas referências e só tenho uma referência a Utility version 1.2.0.203(a outra é antiga).

Alguma sugestão de como descobrir o que está tentando fazer referência a esta versão antiga deste arquivo DLL?

Além disso, acho que nem tenho essa montagem antiga no disco rígido. Existe alguma ferramenta para procurar esse assembly com versão antiga?

O carregador do .NET Assembly:

• é incapaz de encontrar 1.2.0.203
• mas encontrou um 1.2.0.200

Esta montagem não corresponde ao que foi solicitado e, portanto, você recebe esse erro.

Em palavras simples, ele não consegue encontrar a montagem que foi referenciada. Verifique se ele encontra o conjunto correto, colocando-o no GAC ou no caminho do aplicativo. Consulte também https://docs.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference .

Você pode fazer algumas coisas para solucionar esse problema. Primeiro, use a pesquisa de arquivos do Windows para pesquisar sua montagem (.dll) no disco rígido. Depois de ter uma lista de resultados, Exibir-> Escolher detalhes ... e marque "Versão do arquivo". Isso exibirá o número da versão na lista de resultados, para que você possa ver de onde a versão antiga pode estar vindo.

Além disso, como Lars disse, verifique seu GAC para ver qual versão está listada lá. Este artigo da Microsoft afirma que os assemblies encontrados no GAC não são copiados localmente durante uma compilação; portanto, talvez seja necessário remover a versão antiga antes de fazer uma reconstrução total. (Veja minha resposta a esta pergunta para obter notas sobre como criar um arquivo em lotes para fazer isso por você)

Se você ainda não conseguir descobrir de onde vem a versão antiga, poderá usar o aplicativo fuslogvw.exe que acompanha o Visual Studio para obter mais informações sobre as falhas de ligação. A Microsoft tem informações sobre esta ferramenta aqui . Observe que você precisará habilitar o log definindo a HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLogchave do registro como 1.

Eu mesmo me deparei com esse problema e descobri que o problema era algo diferente do que os outros enfrentaram.

Eu tinha duas DLLs que meu projeto principal estava fazendo referência: CompanyClasses.dll e CompanyControls.dll. Eu estava recebendo um erro em tempo de execução dizendo:

Não foi possível carregar o arquivo ou assembly 'CompanyClasses, Versão = 1.4.1.0, Culture = neutral, PublicKeyToken = 045746ba8544160c' ou uma de suas dependências. A definição de manifesto da montagem localizada não corresponde à referência de montagem

O problema era que eu não tinha nenhum arquivo CompanyClasses.dll no meu sistema com um número de versão 1.4.1. Nenhum no GAC, nenhum nas pastas do aplicativo ... nenhum em qualquer lugar. Eu procurei em todo o meu disco rígido. Todos os arquivos CompanyClasses.dll que eu tinha eram 1.4.2.

Eu descobri que o problema real era que o CompanyControls.dll fazia referência à versão 1.4.1 do CompanyClasses.dll. Acabei de recompilar o CompanyControls.dll (depois de o fazer referir ao CompanyClasses.dll 1.4.2) e esse erro desapareceu para mim.

O seguinte redireciona qualquer versão do assembly para a versão 3.1.0.0. Temos um script que sempre atualiza essa referência no App.config para que nunca tenhamos que lidar com esse problema novamente.

Através da reflexão, você pode obter o assembly publicKeyToken e gerar esse bloco a partir do próprio arquivo .dll.

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <dependentAssembly>
    <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" />
  </dependentAssembly>
</assemblyBinding>

Observe que sem um atributo de espaço para nome XML (xmlns), isso não funcionará.

Se você estiver usando o Visual Studio, tente "solução limpa" e reconstrua seu projeto.

As outras respostas não funcionariam para mim. Se você não se importa com a versão e deseja apenas que o aplicativo seja executado, clique com o botão direito do mouse na referência e defina 'version specific' como false ... Isso funcionou para mim.

Acabei de encontrar esse problema e o problema era que eu tinha uma cópia antiga do .dll no diretório de depuração do aplicativo. Você também pode verificar lá (em vez do GAC) para ver se o vê.

Eu vou explodir a mente de todos agora. . .

Exclua todas as <assemblyBinding>referências do seu arquivo .config e execute este comando no console do NuGet Package Manager:

Get-Project -All | Add-BindingRedirect

Adicionei um pacote NuGet, apenas para perceber que uma parte da caixa preta do meu aplicativo estava fazendo referência a uma versão mais antiga da biblioteca.

Eu removi o pacote e referenciei o arquivo DLL estático da versão anterior, mas o arquivo web.config nunca foi atualizado em:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

para o que deveria ter sido revertido quando eu desinstalei o pacote:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

No meu caso, esse erro ocorreu ao executar um aplicativo ASP.NET. A solução foi:

1. Exclua as pastas obje binna pasta do projeto

Limpar não funcionou, reconstruir não funcionou, todas as referências foram boas, mas não estava escrevendo uma das bibliotecas. Depois de excluir esses diretórios, tudo funcionou perfeitamente.

No meu caso, era uma versão antiga da DLL no diretório C: \ WINDOWS \ Microsoft.NET \ Framework \ ~ \ Arquivos temporários do ASP.NET \. Você pode excluir ou substituir a versão antiga ou remover e adicionar novamente a referência à DLL no seu projeto. Basicamente, os dois modos criarão um novo ponteiro para os arquivos ASP.NET temporários.

Para nós, o problema foi causado por outra coisa. O arquivo de licença para os componentes do DevExpress incluía duas linhas, uma para uma versão antiga dos componentes que não estavam instalados neste computador específico. A remoção da versão mais antiga do arquivo de licença resolveu o problema.

A parte irritante é que a mensagem de erro não indicava qual referência estava causando os problemas.

Esse mesmo erro será gerado se você tentar estabelecer uma ligação tardia usando reflexão, se o assembly ao qual você está vinculando tiver um nome forte ou seu token de chave pública alterado. O erro é o mesmo, embora não haja realmente nenhum assembly encontrado com o token de chave pública especificado.

Você precisa adicionar o token de chave pública correto (você pode obtê-lo usando sn -T na dll) para resolver o erro. Espero que isto ajude.

A minha era uma situação muito semelhante à de Nathan Bedford, mas com uma ligeira torção. Meu projeto também referenciou a dll alterada de duas maneiras. 1) Diretamente e 2) Indiretamente, referenciando um componente (biblioteca de classes) que possui uma referência à dll alterada. Agora, meu projeto do Visual Studio para o componente (2) referenciou a versão correta da dll alterada. No entanto, o número da versão do componente em si NÃO foi alterado. E, como resultado, a instalação da nova versão do projeto falhou ao substituir esse componente na máquina cliente.

Resultado final: as referências diretas (1) e indiretas (2) estavam apontando para diferentes versões da dll alterada na máquina cliente. Na minha máquina de desenvolvimento, funcionou bem.

Resolução: remova o aplicativo; Exclua todas as DLLS da pasta do aplicativo; Reinstale. Simples como no meu caso.

Vou deixar alguém se beneficiar da minha estupidez de cisalhamento. Eu tenho algumas dependências para um aplicativo completamente separado (vamos chamar isso de App1). As DLLs desse App1 são inseridas no meu novo aplicativo (App2). Sempre que faço atualizações no APP1, tenho que criar novas dlls e copiá-las para o App2. Bem. . . Cansei de copiar e colar entre duas versões diferentes do App1, então simplesmente adicionei um prefixo 'NEW_' às DLLs.

Bem. . . Eu estou supondo que o processo de compilação varre a pasta / bin e, quando corresponde a algo incorretamente, vomita com a mesma mensagem de erro, conforme observado acima. Eu apaguei minhas versões "new_" e ele criou um dândi.

Meu problema foi copiar o código-fonte para uma nova máquina sem encostar nenhum dos conjuntos mencionados.

Nada que eu corrigi o erro, então, com pressa, excluí o diretório BIN completamente. Reconstruí meu código-fonte e funcionou a partir de então.

Gostaria apenas de acrescentar que estava criando um projeto básico do ASP.NET MVC 4 e adicionado o DotNetOpenAuth.AspNet via NuGet. Isso resultou no mesmo erro depois que eu referenciei um arquivo DLL incompatível para Microsoft.Web.WebPages.OAuth.

Para consertar, fiz um Update-Package e limpei a solução para uma reconstrução completa.

Isso funcionou para mim e é meio preguiçoso, mas tempo é dinheiro :-P

Eu recebi esse erro ao desenvolver o serviço de compilação do Team Foundation Server. Acontece que eu tinha vários projetos em minha solução usando diferentes versões da mesma biblioteca adicionadas ao NuGet. Eu removi todas as versões antigas com o NuGet e adicionei a nova como referência para todos.

O Team Foundation Server coloca todos os arquivos DLL em um diretório e só pode haver um arquivo DLL de um determinado nome por vez.

Meu app.config contém um

<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>

para npgsql. De alguma forma, na máquina do usuário, meu app.exe.config desapareceu. Ainda não tenho certeza se foi um usuário bobo, falha no instalador ou antivírus maluco. A substituição do arquivo resolveu o problema.

Acabei de encontrar outro motivo para obter esse erro. Limpei meu GAC de todas as versões de uma biblioteca específica e construí meu projeto com referência à versão específica implantada junto com o executável. Quando executo o projeto, recebi essa exceção procurando uma versão mais recente da biblioteca.

O motivo foi a política do editor . Quando desinstalei as versões da biblioteca do GAC, esqueci de desinstalar também os assemblies de política do editor. Em vez de usar meu assembly implantado localmente, o carregador de montagem encontrou a política do editor no GAC, que o instruiu a procurar uma versão mais recente.

Para mim, a configuração da cobertura do código no arquivo "Local.testtesttings" "causou" o problema. Esqueci de atualizar os arquivos que foram referenciados lá.

Apenas excluir o conteúdo da pasta bin do seu projeto e reconstruir a solução resolveu meu problema.

limpar e reconstruir a solução pode não substituir todas as dlls do diretório de saída.

o que eu sugiro é tentar renomear a pasta de "bin" para "oldbin" ou "obj" para "oldobj"

e tente construir sua siluição novamente.

caso você esteja usando alguma DLL de terceiros, será necessário copiar para a pasta "bin" ou "obj" recém-criada após a compilação bem-sucedida.

Espero que isto funcione para voce.

Excluir manualmente a montagem antiga do local da pasta e adicionar a referência a novas montagens pode ajudar.

Eu recebi o mesmo erro ... No meu caso, foi resolvido da seguinte maneira:

• No início, quando o aplicativo foi instalado, as pessoas aqui haviam usado o Microsoft Enterprise Library 4.1 no aplicativo.
• Na semana anterior, minha máquina foi formatada e, depois disso, hoje, quando criei esse aplicativo, ocorreu um erro de falta de montagem da Biblioteca da Empresa.
• Em seguida, instalei o Microsoft Enterprise Library 5.0, que recebi no Google como primeira entrada de pesquisa.
• Então, quando criei o aplicativo, ele me deu o erro acima, ou seja, a definição do manifesto do assembly localizado não corresponde à referência do assembly.
• Depois de muito trabalho e análise de pesquisa, descobri que o aplicativo estava se referindo à 4.1.0.0 e a DLL na pasta bin era da versão 5.0.0.0
• O que fiz foi instalar a Microsoft Enterprise Library 4.1.
• Removida a referência anterior (5.0) e adicionada a referência 4.0.
• Construiu o aplicativo e pronto ... funcionou.

Aqui está o meu método de corrigir esse problema.

1. Na mensagem de exceção, obtenha o nome da biblioteca "problem" e o número da versão "esperada".

2. Encontre todas as cópias desse arquivo .dll na sua solução, clique com o botão direito do mouse neles e verifique qual versão do arquivo .dll é.

Ok, então, neste exemplo, minha .dll é definitivamente 2.0.5022.0 (portanto, o número da versão da exceção está errado).

3. Procure o número da versão que foi mostrado na mensagem Exceção em todos os arquivos .csproj em sua solução. Substitua este número de versão pelo número real da DLL.

Então, neste exemplo, eu substituiria isso ...

<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

... com isso...

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

Tarefa concluída !

No meu caso, o problema estava entre a cadeira e o teclado :-)

Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)

Dois ou mais assemblies diferentes queriam usar uma versão diferente da biblioteca DotNetOpenAuth, e isso não seria um problema. Além disso, no meu computador local, o web.config foi atualizado automaticamente pelo NuGet:

<dependentAssembly>
    <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
    </dependentAssembly>
    <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
</dependentAssembly>

Então percebi que havia me esquecido de copiar / implantar o novo web.config no servidor de produção. Portanto, se você tiver uma maneira manual de implantar o web.config, verifique se ele está atualizado. Se você tiver web.config completamente diferente para o servidor de produção, precisará mesclar essas seções dependentesAssembly em sincronia depois de usar o NuGet.

Se você receber um erro como " A definição de manifesto do assembly localizado não coincide com a referência do assembly " e se você atualizou através da guia Projeto> Gerenciar pacotes NuGet e atualização no VS , a primeira coisa que você pode fazer é tentar instalar outra versão do pacote após verificar as versões da página NuGet Gallery e executar o seguinte comando no Package Manager Console:

PM> Install-Package YourPackageName -Version YourVersionNumber 
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0

Embora a resposta não esteja diretamente relacionada ao pacote em questão e tenha sido solicitada há muito tempo, é meio genérica, ainda relevante e espero que ajude alguém.

Nenhuma solução funcionou para mim. Tentei limpar a solução do projeto, remover o bin, atualizar o pacote, fazer o downgrade do pacote e assim por diante ... Depois de duas horas, carreguei o App.config padrão do projeto com assemblies e alterei a versão de referência incorreta de:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

para:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

Depois disso, limpei o projeto, construí-lo novamente e funcionou. Sem aviso não há problema.

Recebi esta mensagem de erro devido à referência a um assembly que tinha o mesmo nome que o assembly que eu estava construindo.

Isso compilou, mas substituiu o assembly referenciado pelo assembly de projetos atual - causando o erro.

Para corrigi-lo, alterei o nome do projeto e as propriedades da montagem disponíveis clicando com o botão direito do mouse no projeto e escolhendo 'Propriedades'.