O localizada definição do manifesto do assembly não corresponde à referência do assembly

https://stackoverflow.com/questions/215026

03-07-2019
|

Pergunta

Eu estou tentando executar alguns testes de unidade em um aplicativo de formulários do Windows C # (Visual Studio 2005), e eu recebo o seguinte erro:

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

no x.Foo.FooGO ()

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

no x.Foo.UnitTests.FooTests.TestFoo () in FooTests.cs: Linha 98 **

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

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

Todas as sugestões sobre como eu descobrir o que está tentando fazer referência a esta versão antiga deste arquivo DLL?

Além disso, eu não acho que eu ainda tenho esta assembléia de idade no meu disco rígido. Existe alguma ferramenta de pesquisa para este velho versionadas montagem?

Solução

A Assembleia .NET loader é incapaz de encontrar 1.2.0.203, mas fez encontrar um 1.2.0.200. Esta montagem não coincide com o que foi pedido e, portanto, você receber esse erro. Em palavras simples, ele não pode encontrar o conjunto que foi referenciado. Certifique-se de que pode encontrar o conjunto da direita, colocando-o no GAC ou no caminho do aplicativo. Veja também http://blogs.msdn.com/junfeng/archive /2004/03/25/95826.aspx .

Outras dicas

Você pode fazer um par de coisas para resolver este problema. Primeiro, use o Windows pesquisa de arquivo para pesquisar seu disco rígido para o seu assembly (.dll). Uma vez que você tem uma lista de resultados, faça Ver-> Escolha Detalhes ... e marque "File Version". Isto irá exibir o número da versão na lista de resultados, para que possa ver onde a versão antiga pode estar vindo.

Além disso, como Lars disse, verifique o GAC para ver qual versão está listado lá. estados este artigo Microsoft que as assembléias encontrado no GAC não são copiados localmente durante uma compilação, de modo que você pode precisar remover a versão antiga antes de fazer uma reconstrução tudo. (Veja a minha resposta para este pergunta para notas sobre a criação de um arquivo de lote para fazer isso para você)

Se você ainda não pode descobrir onde a versão antiga está vindo, você pode usar o aplicativo Fuslogvw.exe que vem com o Visual Studio para obter mais informações sobre as falhas de ligação. Microsoft tem informações sobre esta ferramenta aqui . Note que você terá que activar o registo, definindo a chave de registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog a 1.

Eu apenas corri para este problema sozinho, e eu achei que a questão era diferente algo do que o que os outros têm executado em.

Eu tinha dois DLLs que o meu projeto principal foi referenciando: CompanyClasses.dll e CompanyControls.dll. Eu estava recebendo um erro de tempo de execução dizendo:

Não foi possível carregar arquivo ou assembly 'CompanyClasses, versão = 1.4.1.0, Culture = neutral, PublicKeyToken = 045746ba8544160c' ou uma das suas dependências. o localizada Definição de manifesto do assembly faz não corresponde a referência assembly

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

O verdadeiro problema, eu encontrei, foi que CompanyControls.dll versão 1.4.1 do CompanyClasses.dll referenciado. Eu só recompilados CompanyControls.dll (após tê-lo referência CompanyClasses.dll 1.4.2) e este erro foi embora para mim.

Os seguintes redirecionamentos qualquer versão de montagem para a versão 3.1.0.0. Nós temos um script que sempre vai atualizar esta referência no App.config para que nunca tem que lidar com esta questão novamente.

Através da reflexão você pode começar a montagem publicKeyToken e gerar este bloco do ficheiro .dll em si.

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

Note que sem um atributo namespace XML (xmlns) isto não vai funcionar.

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

As outras respostas não iria funcionar para mim. Se você não se preocupam com a versão e você só quer o seu aplicativo para executar, em seguida, clique direito sobre a referência e set 'versão específica' para false ... Isso funcionou para mim. enter descrição da imagem aqui

Eu só corri em toda esta questão e que o problema era que eu tinha uma cópia antiga do arquivo .dll no meu diretório de depuração do aplicativo. Você pode querer verificar também lá (em vez do GAC) para ver se você vê-lo.

Eu adicionei um pacote NuGet, apenas para perceber uma parte da caixa preta da minha candidatura foi referenciando uma versão mais antiga da biblioteca.

Eu removi o pacote e referenciado arquivo DLL estática da versão mais antiga, mas o arquivo web.config não foi atualizado a partir de:

<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 revertido para quando eu desinstalado 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, este erro ocorreu durante a execução de uma aplicação ASP.NET. A solução foi:

Exclua as pastas obj e bin no projeto pasta

Limpo não funcionou, reconstrução não funcionou, todas as referências eram bons, mas não estava escrevendo uma das bibliotecas. Depois de excluir os diretórios, tudo funcionou perfeitamente.

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

Vou mente golpe de todos agora. . .

Excluir todas as referências <assemblyBinding> de seu arquivo config, e depois executar este comando a partir do Gerenciador de Pacotes consola NuGet:

Get-Project -All | Add-BindingRedirect

Para nós, o problema foi causado por outra coisa. O arquivo de licença para os componentes DevExpress incluiu duas linhas, uma para uma versão antiga dos componentes que não foi instalado neste computador particular. Removendo a versão mais antiga do arquivo de licença resolvido a questão.

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

Este mesmo erro exato é lançada se você tentar tarde ligam usando a reflexão, se a montagem estiver a vincular a recebe de nome forte ou tem o seu público-chave simbólica alterado. O erro é o mesmo, embora não há realmente qualquer montagem encontrado com o símbolo de chave pública especificada.

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

A minha era uma situação muito semelhante à mensagem por Nathan Bedford, mas com uma leve torção. Meu projeto também referenciada a dll alterado de duas formas. 1) directamente e 2) Indirectamente, por referência a um componente (biblioteca de classes) que se tinha uma referência para a dll alterado. Agora meu projeto do Visual Studio para o componente (2) referenciados a versão correta do dll alterado. No entanto, o número da versão da própria compnent não foi alterado. E como resultado a instalação da nova versão do projeto falhou para substituir esse componente na máquina do cliente.

O resultado final: referência directo (1) e a referência indirecta (2) foram apontando para diferentes versões do DLL alterado no equipamento do cliente. Na minha máquina dev ele funcionou bem.

Resolução: Remover aplicação; Excluir todas as DLLs da pasta de aplicação; Re-install.Simple como que no meu caso.

Eu vou deixar alguém beneficiar de minha estupidez cisalhamento. Eu tenho algumas dependências para uma aplicação completamente separado (chamado de deixar este App1). A dll de que App1 são puxados para o meu novo aplicativo (App2). Toda vez que eu fazer atualizações no APP1, eu tenho que criar uma nova DLL e copiá-los para App2. Bem. . .Eu fiquei cansado de copiar e colar entre 2 versões diferentes App1, então eu simplesmente adicionou um 'New_' prefixo para o dll de.

Bem. . . Eu estou supondo que o processo de compilação verifica a pasta / bin e quando ele corresponde algo incorretamente, barfs com a mesma mensagem de erro como mencionado acima. Eu apaguei meus versões "New_" e é construída apenas dandy.

Meu problema foi copiar o código-fonte para uma nova máquina sem puxar sobre qualquer um dos assemblies referenciados.

Nada que eu tinha fixado o erro, por isso na pressa, eu deletei o diretório BIN completamente. Reconstruída meu código-fonte, e trabalhou a partir de então em diante.

Eu gostaria apenas de acrescentar que eu estava criando um projeto básico ASP.NET MVC 4 e acrescentou DotNetOpenAuth.AspNet via NuGet. Isto resultou no mesmo erro depois que eu referenciado um arquivo DLL descasamento para Microsoft.Web.WebPages.OAuth.

Para corrigir isso eu fiz um Update-Package e limpos a solução para uma reconstrução completa.

Isso funcionou para mim e é uma espécie de uma forma preguiçosa, mas o tempo é dinheiro :-P

Eu tenho esse erro ao construir on-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 adicionados com NuGet. Tirei todas as versões antigas com NuGet e acrescentou 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 de cada vez, claro.

O 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, minha app.exe.config desapareceu. Eu não tenho certeza se ele era um usuário bobo, instalador falha, ou wacked para fora anti-vírus ainda. Substituir o arquivo resolveu o problema.

Eu encontrei outra razão pela qual a obter este erro. Eu limpo o meu GAC de todas as versões de uma biblioteca específica e construí o meu projeto com referência a versão específica enviar juntamente com o executável. Quando eu executar o projeto eu tenho essa busca exceção para uma versão mais recente da biblioteca.

A razão era publisher política . Quando as versões I da biblioteca desinstalado do GAC eu esqueci de assembleias políticas editor de desinstalação, bem assim em vez de usar a minha montagem do carregador de assembly implantado localmente encontrados política de editor no GAC, que lhe disse para procurar uma versão mais recente.

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

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

limpa e reconstruir a solução pode não substituir todos os dll de partir o diretório de saída.

O que vou sugerir é tentar mudar o nome da pasta de "bin" para "oldbin" ou "obj" para "oldobj"

e, em seguida, tentar construir a sua silution novamente.

encerra se você estiver usando qualquer dll terceiros é aqueles que você precisará copiar para recém-criado "bin" ou pasta "obj" depois de compilação bem-sucedida.

Esperamos que este irá trabalhar para você.

manualmente apagar a antiga montagem da localização da pasta e, em seguida, adicionando a referência a novas montagens pode ajudar.

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

Na primeira, quando o aplicativo foi instalado, em seguida, as pessoas aqui tinha usado Microsoft Enterprise Library 4.1 no aplicativo.
Na semana anterior a minha máquina foi formatado e depois disso hoje, quando eu construí esse aplicativo, em seguida, deu-me um erro que Enterprise Library montagem está faltando.
Em seguida, instalou o Microsoft Enterprise Library 5.0 que eu tenho no Google como primeira entrada de pesquisa.
Então, quando eu construí a aplicação, em seguida, deu-me o erro acima ou seja, O localizada montagem é definição manifesto não corresponde à referência do assembly.
Depois de muito de um trabalho de pesquisa e análise, eu achei que a aplicação 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, em seguida, eu instalei o Microsoft Enterprise Library 4.1.
Removida a referência anterior (5.0) e acrescentou a referência 4.0.
Construído a aplicação e voila ... funcionou.

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

Na mensagem de exceção, obter o nome da biblioteca "problema" e o número da versão "esperado".

Encontre todas as cópias de que .dll em sua solução, clique com botão direito sobre eles, e verificar qual a versão do que .dll é.

Ok, então neste exemplo, o meu .dll é definitivamente 2.0.5022.0 (por isso o número da versão Exceção é errado).

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

Assim, neste exemplo, eu iria substituir isso ...

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

... com esta ...

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

feito trabalho!

No meu caso era o problema entre a cadeira eo 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 queria 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:

<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 eu percebi que eu tinha esquecido de copiar / implantar o novo web.config para o servidor de produção. Então se você tem forma manual de implantação web.config, verifique se está atualizado. Se você tem web.config completamente diferente para servidor de produção, você tem que juntar estes seção dependentAssembly em sincronia depois de usar o NuGet.

Se você nunca obter um erro como " O localizada montagem é definição manifesto não corresponde à referência do assembly ", e se você tiver atualizado via Project> Gerenciar Pacotes NuGet e guia Atualização em VS , a primeira coisa que você poderia fazer é tentar instalar outra versão do pacote depois de verificar as versões de NuGet Gallery página e executando o comando folowing de Package Manager Console:

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

Apesar de resposta não está directamente relacionado com o pacote em questão e foi solicitado caminho de volta, ele é uma espécie de genérico, ainda é relevante e espero que ajude alguém.

Recebi esta mensagem de erro devido a referência a um conjunto que tinha o mesmo nome que a assembléia estava a construir.

Este compilado mas substituiu a referência de montagem com os projetos atuais de montagem -. Causando o erro

Para corrigir isso eu mudei o nome do projeto, e as propriedades de montagem disponíveis através do botão direito do mouse no projeto e escolha 'Propriedades'.

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

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow