A definição de manifesto do assembly localizado não corresponde à referência de assembly

Eu 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, Version = 1.2.0.200, Culture = neutral, PublicKeyToken = 764d581291d764f7’ ou uma de suas dependencies. A definição de manifesto do assembly localizado não corresponde à referência de assembly. (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, Version = 1.2.0.203, Culture = neutral, PublicKeyToken = 764d581291d764f7’ ou uma de suas dependencies. A definição de manifesto do assembly localizado não corresponde à referência de assembly. (Exceção de HRESULT: 0x80131040)

Eu olho em minhas referências, e eu só tenho uma referência ao Utility version 1.2.0.203 (o outro é antigo).

Alguma sugestão sobre como eu descobrir o que está tentando referenciar esta versão antiga deste arquivo DLL?

Além disso, acho que nem tenho essa antiga assembly no meu disco rígido. Existe alguma ferramenta para procurar por este antigo assembly versionado?

O carregador do .NET Assembly não consegue encontrar o 1.2.0.203, mas encontrou um 1.2.0.200. Essa assembly não corresponde ao que foi solicitado e, portanto, você recebe esse erro. Em palavras simples, não é possível encontrar o assembly que foi referenciado. Certifique-se de que ele possa encontrar o assembly correto, colocando-o no GAC ou no caminho do aplicativo. Veja também http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx .

Você pode fazer algumas coisas para solucionar esse problema. Primeiro, use a pesquisa de arquivos do Windows para pesquisar em seu disco rígido por seu assembly (.dll). Uma vez que você tenha uma lista de resultados, faça View-> Choose Details … e então marque “File Version”. 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 o Lars disse, verifique seu GAC para ver qual versão está listada lá. Este artigo da Microsoft afirma que assemblies encontrados no GAC não são copiados localmente durante uma compilation, portanto, talvez seja necessário remover a versão antiga antes de recriar todos. (Veja a minha resposta a esta pergunta para notas sobre como criar um arquivo de lote 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 binding. A Microsoft tem informações sobre essa ferramenta aqui . Observe que você terá que habilitar o log definindo a chave do Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog como 1.

Acabei de me deparar com esse problema e descobri que o problema era 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, Version = 1.4.1.0, Culture = neutral, PublicKeyToken = 045746ba8544160c’ ou uma de suas dependencies. A definição de manifesto do assembly localizado não corresponde à referência de assembly

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 de aplicativos … nenhum em lugar algum. Eu procurei meu disco rígido inteiro. Todos os arquivos CompanyClasses.dll que eu tinha eram 1.4.2.

O problema real, eu encontrei, foi que CompanyControls.dll referenciado a versão 1.4.1 do CompanyClasses.dll. Acabei de recompilar CompanyControls.dll (depois de ter referência CompanyClasses.dll 1.4.2) e esse erro foi embora para mim.

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

Através da reflection você pode obter o assembly publicKeyToken e gerar este bloco a partir do próprio arquivo .dll.

       

Observe que sem um atributo de namespace XML (xmlns) isso não funcionará.

Se você estiver usando o Visual Studio, tente “solução limpa” e, em seguida, recrie seu projeto.

Se você não se importa com a versão e quer apenas que seu aplicativo seja executado, clique com o botão direito do mouse na referência e defina “versão específica” como falsa. As outras soluções não funcionariam para mim. insira a descrição da imagem aqui

Acabei de me deparar com esta questão e o problema foi que eu tinha uma cópia antiga do .dll no meu diretório de debugging do aplicativo. Você também pode querer verificar lá (em vez do GAC) para ver se você o vê.

Eu adicionei um pacote NuGet, apenas para perceber que uma parte da checkbox 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 mais antiga, mas o arquivo web.config nunca foi atualizado de:

     

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

     

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

No meu caso, esse erro ocorreu durante a execução de um aplicativo ASP.NET. A solução foi:

  1. Exclua as pastas obj e bin na pasta do projeto

Clean não funcionou, reconstrução não funcionou, todas as referências estavam bem, mas não estava escrevendo uma das bibliotecas. Depois de excluir esses diretórios, tudo funcionou perfeitamente.

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 estava instalada neste computador específico. Remover a versão mais antiga do arquivo de licença resolveu o problema.

A parte chata é que a mensagem de erro não deu nenhuma indicação sobre qual referência estava causando os problemas.

Esse mesmo erro é lançado se você tentar vincular tardiamente usando reflection, se o assembly ao qual você está vinculando ficar com um nome forte ou tiver seu token de chave pública alterado. O erro é o mesmo, embora não exista 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.

O meu era uma situação muito semelhante ao post de Nathan Bedford, mas com uma leve reviravolta. Meu projeto também referenciou a dll alterada de duas maneiras. 1) Diretamente e 2) Indiretamente referenciando um componente (biblioteca de classs) que em si tinha uma referência à dll alterada. Agora meu projeto do Visual Studio para o componente (2) fez referência à versão correta da dll alterada. No entanto, o número da versão do próprio componente NÃO foi alterado. E como resultado, a instalação da nova versão do projeto não conseguiu replace esse componente na máquina cliente.

Resultado final: Referência direta (1) e Referência indireta (2) apontavam para versões diferentes da dll alterada na máquina cliente. Na minha máquina dev funcionou bem.

Resolução: remova o aplicativo; Exclua todas as DLLs da pasta do aplicativo; Re-install.Simple como no meu caso.

Eu vou deixar alguém se beneficiar da minha estupidez. Eu tenho algumas dependencies para um aplicativo completamente separado (vamos chamar isso de App1). A DLL do App1 é puxada para o meu novo aplicativo (App2). Sempre que faço atualizações no APP1, tenho que criar novas dll’s e copiá-las para o App2. Bem. . .Eu me cansei de copiar e colar entre 2 versões diferentes do App1, então eu simplesmente adicionei um prefixo ‘NEW_’ ao dll.

Bem. . . Eu estou supondo que o processo de compilation varre a pasta / bin e quando coincide com algo incorretamente, vomita com a mesma mensagem de erro como mencionado acima. Eu apaguei as minhas versões “new_” e elas foram construídas apenas como dandy.

Meu problema era copiar o código-fonte para uma nova máquina sem executar nenhum dos assemblies referenciados.

Nada que eu fiz consertou o erro, então na pressa, eu apaguei o diretório BIN completamente. Reconstruiu meu código-fonte e funcionou a partir de então.

Eu gostaria apenas de acrescentar que eu estava criando um projeto ASP.NET MVC 4 básico e adicionei o DotNetOpenAuth.AspNet via NuGet. Isso resultou no mesmo erro após eu referenciei um arquivo DLL incompatível para Microsoft.Web.WebPages.OAuth.

Para corrigi-lo eu fiz um Update-Package e limpei a solução para uma reconstrução completa.

Isso funcionou para mim e é uma maneira preguiçosa, mas tempo é dinheiro 😛

Eu recebi esse erro ao criar o serviço de compilation do Team Foundation Server. Aconteceu que eu tinha vários projetos na minha solução usando versões diferentes da mesma biblioteca adicionada ao NuGet. Eu removi todas as versões antigas com o NuGet e adicionei o novo como referência para todos.

Team Foundation Server coloca todos os arquivos DLL em um diretório, e só pode haver um arquivo DLL de um determinado nome em um momento claro.

Acabei de encontrar outro motivo para obter esse erro. Limpei o GAC de todas as versões de uma biblioteca específica e criei meu projeto com referência à versão específica implantada junto com o executável. Quando executo o projeto, recebo esta exceção procurando por uma versão mais nova 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 diretivas de editores. Em vez de usar o assembly implantado localmente, o carregador de assembly encontrou a diretiva de publicador no GAC, que solicitou uma versão mais recente.

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

Meu app.config contém um

  

para npgsql. De alguma forma na máquina do usuário, meu app.exe.config desapareceu. Eu não tenho certeza se foi um usuário bobo, falha do instalador, ou wacked anti-virus ainda. Substituir o arquivo resolveu o problema.

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

o que eu vou sugerir é tentar renomear a pasta de “bin” para “oldbin” ou “obj” para “oldobj”

e tente construir sua silencia novamente.

Encheckboxr se você estiver usando qualquer dll de terceiros que você precisará copiar em pasta “bin” ou “obj” recém-criado após a compilation bem-sucedida.

Espero que isto funcione para voce.

Excluir manualmente o conjunto antigo do local da pasta e, em seguida, adicionar a referência a novos conjuntos pode ajudar.

Eu tenho o mesmo erro … No meu caso, foi resolvido da seguinte forma:

  • No início, quando o aplicativo foi instalado, as pessoas aqui usaram o Microsoft Enterprise Library 4.1 no aplicativo.
  • Na semana anterior, minha máquina foi formatada e, depois disso, hoje, quando eu criei esse aplicativo, ocorreu um erro no qual a assembly da Biblioteca Corporativa está ausente.
  • Em seguida, instalei o Microsoft Enterprise Library 5.0, que obtive no Google como primeira input de pesquisa.
  • Então, quando eu construí 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 de um trabalho de pesquisa e análise, 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 eu fiz foi então eu instalei o Microsoft Enterprise Library 4.1.
  • Removida a referência anterior (5.0) e adicionada a referência 4.0.
  • Construiu o aplicativo e voila … funcionou.

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

  1. Da mensagem de exceção, obtenha o nome da biblioteca “problemática” e o número da versão “esperada”.

insira a descrição da imagem aqui

  1. Encontre todas as cópias desse arquivo .dll em sua solução, clique com o botão direito do mouse sobre ele e verifique a versão do arquivo .dll.

insira a descrição da imagem aqui

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

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

Então, neste exemplo, eu replaceia isso …

  

… com isso…

  

Tarefa concluída !

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

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 conjuntos diferentes desejavam usar uma versão diferente da biblioteca DotNetOpenAuth e isso não seria um problema. Além disso, no meu computador local, um web.config foi atualizado automaticamente pelo NuGet:

         

Então percebi que havia 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 um web.config completamente diferente para o servidor de produção, será necessário mesclar essa seção dependentAssembly em sincronia depois de usar o NuGet.

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

Isso compilado, mas substituiu o assembly referenciado com o assembly de projetos atual – causando o erro.

Para corrigi-lo, mudei o nome do projeto e as propriedades de assembly disponíveis, clicando com o botão direito do mouse no projeto e escolhendo ‘Propriedades’.

Em sua AssemblyVersion no arquivo AssemblyInfo.cs, use um número de versão fixo em vez de especificar *. O * irá alterar o número da versão em cada compilation. Esse foi o problema para essa exceção no meu caso.

Eu corri para este problema ao usar um repository interno de pacotes. Eu adicionei o pacote principal ao repository interno, mas não as dependencies do pacote. Certifique-se de adicionar todas as dependencies, dependencies de dependencies, etc recursivas ao seu repository interno também.

Eu tive o mesmo problema hoje que me impediu de executar o Add-Migration depois que fiz alterações no Entity Framework.

Eu tinha dois projetos na minha solução, vamos chamá-los de “Client” e “Data” – um projeto de biblioteca de classs que mantinha meus modelos EF e contexto. O cliente referenciou o projeto de dados.

Eu tinha assinado ambos os projetos e depois fiz alterações em um modelo EF. Depois que removi a assinatura, consegui adicionar as migrações e, em seguida, assinei o projeto novamente.

Espero que isso possa ser útil para alguém, poupando-os de uma frustração prolongada.