Não foi possível carregar o arquivo ou o assembly ou uma de suas dependências

238

Estou com outro problema "Não foi possível carregar o arquivo ou o assembly ou uma de suas dependências".

Informações adicionais: Não foi possível carregar o arquivo ou assembly 'Microsoft.Practices.Unity, Versão = 1.2.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35' 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)

Não tenho idéia do que está causando isso ou como eu poderia depurá-lo para encontrar a causa.

Fiz uma pesquisa em meus catálogos de solução .csproj e em todos os lugares em que tenho o Unity, tenho:

Referência Include = "Microsoft.Practices.Unity, Versão = 2.0.414.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL"

Não consigo encontrar nenhuma referência em nenhum lugar que vá contra a 1.2.0.0 em qualquer um dos meus projetos.

Alguma idéia de como devo resolver isso?

Também gostaria de receber dicas sobre como depurar problemas como esse em geral.

ronag
fonte
1
Algum dos seus assemblies referenciados pode estar usando algumas coisas na Unitybiblioteca antiga ?
Decyclone
3
Provavelmente ... mas como posso encontrar quais montagens? Eu tenho um monte de projetos na minha solução e um monte de potenciais suspeitos ... tentativa e erro bruteforce parece um pouco sem esperança ...
ronag
3
Não é a referência de montagem, você faz referência à versão 2.0. Mas no tempo de execução, o CLR está encontrando a versão 1.2, antiga. Se você não encontrar essa DLL antiga no diretório de compilação, use o Fuslogvw.exe para descobrir como o CLR encontrou essa cópia antiga.
Hans Passant
2
Olhe para a pasta bin do seu projeto e veja se a DLL do seu projeto está em conflito com o nome. Apenas exclua esse e então reconstrua sua solução. Isso funcionou para mim.
Coggicc 30/07/2015
11
"ou uma de suas dependências" é a parte que realmente me irrita. Se ele não puder carregar "uma de suas dependências", o erro deve dizer qual "uma de suas dependências" não pode ser carregada. A forma atual é inútil, ele poderia muito bem dizer não pode carregar thinggy
Paul McCarthy

Respostas:

116
  1. Verifique se você está fazendo referência a uma montagem que, por sua vez, faz referência a uma versão antiga da unidade. Por exemplo, digamos que você tenha um assembly chamado ServiceLocator.dllque precisa de uma versão antiga do assembly do Unity, agora, quando você fizer referência ao, ServiceLocatordeverá fornecer a versão antiga do Unity e isso causará o problema.

  2. Pode ser a pasta de saída onde todos os projetos constroem suas montagens, tem uma versão antiga da unidade.

Você pode usar o FusLogVw para descobrir quem está carregando os assemblies antigos, basta definir um caminho para o log e executar sua solução, depois verificar (no FusLogvw) a primeira linha em que o assembly do Unity está carregado, clique duas vezes nele e veja a chamada. montagem, e aqui vai você.

Nour Sabouny
fonte
6
Onde está o arquivo de log de FuseLogVw
Stiger
1
Para evitar a localização do arquivo de log, você pode especificar um caminho de log personalizado: Configurações, marque a caixa de seleção Ativar caminho de log personalizado, insira um caminho de log personalizado e atualize.
RedGreenCode
82

Abra o Gerenciador do IIS

Selecionar pools de aplicativos

depois selecione o pool que você está usando

vá para configurações avançadas (no lado direito)

Altere o sinalizador de Ativar aplicativo de 32 bits falso para verdadeiro.

kranthi
fonte
IIS -> selecione cada ApplicationPool -> Configurações básicas -> verifique se a estrutura mais recente está selecionada no menu suspenso "Versão do .NET Framework"
Martin
Você também pode clicar com o botão direito do mouse no seu projeto no VS. e retire a preferência de 32 bits marca
eran otzap
Obrigado. Funcionou. Bem, já era verdade no meu caso, apenas para tentar. Eu fiz falso e funcionou.
precisa saber é o seguinte
Quando mesclei um projeto de um servidor para outro, esse sinalizador estava mesmo falso novamente, obrigado pela solução!
Appsum Solutions 27/11/19
69

Para mim, nenhuma das outras soluções funcionou (incluindo a estratégia de limpeza / reconstrução). Encontrei outra solução alternativa que é fechar e reabrir o Visual Studio .

Eu acho que isso força o Visual Studio a recarregar a solução e todos os projetos, verificando novamente as dependências no processo.

Robotnik
fonte
33
Se você não acredita que isso funcionará, pelo menos tente. Eu não conseguia acreditar até acreditar.
Ben Cull
3
😍😍😍😍😍😍😍😍😍😍😍 Trabalhou para mim #
Devidas M Das
48

Tente limpar as pastas Debug e Release na sua solução. Em seguida, remova e adicione a unidade novamente.

Aleksei Anufriev
fonte
3
Esse problema pode ser causado por muitas coisas ... sua solução resolveu meus problemas e pode resolver os outros também.
Scott Rippey
1
@ ScottRippey Isso funcionou para mim. Primeiro, excluí todos os arquivos .pdb e, em seguida, recarreguei meu projeto e o reconstruí.
botenvouwer
21

Em 99%, o problema Não foi possível carregar o arquivo ou o assembly ou um de seus dependências é causado por dependências! Eu sugiro que você siga estas etapas:

  1. Faça o download do Dependency Walker em http://www.dependencywalker.com/

  2. Inicie o Dependency Walker e abra a dll (no meu caso NativeInterfaces.dll)

  3. Você pode ver uma ou mais dll com o erro vermelho Erro ao abrir o arquivo ...

  4. Isso significa que essa dll está ausente no seu sistema; no meu caso, o nome da dll éMSVCR71.DLL

  5. Você pode baixar dll missings do google e copiar no caminho certo (no meu caso c:\windows\system32)

  6. Nesse ponto, você deve registrar a nova dll no GAC (Global Assembly Cache): abra um terminal do DOS e escreva:

    cd \Windows\System32
    regsvr32 /i msvcr71.dll
  7. Reinicie seu aplicativo!

Stefano Lonati
fonte
22
O walker de dependência é ótimo, mas copiar DLLs aleatórias da Internet para o Windows é ... menos excelente. É melhor tentar encontrar o instalador que fornece essas DLLs.
RJFalconer
Eu obtive alguns arquivos ( API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-1.DLL) não encontrados e me levou a essa pergunta sobre o stackoverflow . Basicamente, lembre-se de que pode estar olhando para falso positivo em alguns arquivos, o link fornece mais detalhes.
Cheriejw 15/05
16

O Microsoft Enterprise Library (referenciado por .NetTiers) foi o nosso problema, que por sua vez fazia referência a uma versão mais antiga do Unity. Para resolver o problema, usamos o seguinte redirecionamento de ligação no web.config:

<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Practices.Unity.Configuration" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

Como alternativa, você pode apenas atualizar a Enterprise Library para a versão mais recente.

Rebecca
fonte
16

A seguir funcionou para mim.

  • Remover arquivos temporários C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Arquivos ASP.NET temporários
  • Feche o VSTS e abra novamente
  • Remova e adicione as mesmas DLLs (Nota: você adiciona as mesmas versões correspondentes)
Riddhi M.
fonte
15

Verifique o arquivo Web.config / App.config no seu projeto. Veja se os números da versão estão corretos.

<bindingRedirect oldVersion="X.X.X.X-X.X.X.X" newVersion="X.X.X.X" />

Isso funcionou para mim.

Jaseem Abbas
fonte
2
Isso funcionou para mim, embora fosse web.config, não app.config
samneric
15

Apesar de a pergunta original ter sido publicada há cinco anos, o problema ainda persiste e é bastante irritante.

A solução geral é a análise completa de todos os assemblies referenciados para entender o que está acontecendo de errado. Para facilitar essa tarefa, criei uma ferramenta (uma extensão do Visual Studio) que permite selecionar um assembly .NET (um .dllou .exearquivo) para obter um gráfico de todos os assemblies referenciados enquanto destaca referências ausentes ou conflitantes.

A ferramenta está disponível na Galeria do Visual Studio: https://marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734

Exemplo de saída: insira a descrição da imagem aqui

marss19
fonte
Não funciona com as edições do Visual Studio da
Comunidade
Acredito que deve haver outro problema, não relacionado à edição do Visual Studio. Testei a extensão nas edições VS 2017 e VS 2015 Community. Na verdade, foi desenvolvido por meio da edição VS 2017 Community.
precisa saber é
Aha. Você tem outras extensões instaladas? Esta página diz que o DGML não é suportado na Comunidade VS: msdn.microsoft.com/en-us/library/hh871439.aspx#VersionSupport
Draex_
1
Não há ferramentas de arquitetura na edição comunitária, mas o próprio editor DGML está disponível. Você pode instalá-lo selecionando "Instalar DGML editor" em "Componentes Individual" -> "Ferramentas de código" via Visual Studio Installer -> Modificar
marss19
11

captura de telaNo gerenciador de soluções, clique com o botão direito do mouse no projeto (não na solução), na guia compilar, escolha Destino da plataforma: "Qualquer CPU".

Engin Aydogdu
fonte
Após verificar o pool de aplicativos, "Ativar aplicativos de 32 bits" foi definido como False, mas o destino da minha plataforma era x86. Alterá-lo para Qualquer CPU OU x64 corrigiu meu problema.
precisa
11

A resposta Juntos está correta, mas você também deve considerar:

Pela unidade v2.1.505.2 diferentes AssemblyVersion e AssemblyFileVersion atributos são especificados:

insira a descrição da imagem aqui

AssemblyFileVersion é usado pelo NuGet, mas o CLR não se importa com isso! O CLR usará apenas AssemblyVersion !

Portanto, seus redirecionamentos devem ser aplicados a uma versão especificada no atributo AssemblyVersion . Então 2.1.505.0 deve ser usado

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.1.505.0" newVersion="2.1.505.0" />
</dependentAssembly>
</assemblyBinding>

Consulte também: Quais são as diferenças entre AssemblyVersion, AssemblyFileVersion e AssemblyInformationalVersion?

Ievgen Naida
fonte
6

Eu também recebi esse erro terrível e encontrei uma solução para isso ...

  1. Clique com o botão direito do mouse no nome da solução
  2. Clique em Solução Limpa
  3. Reinicie o Visual Studio
  4. Saltar projeto Propriedades >> Compilar
  5. Alterar configuração para liberação
  6. Iniciar depuração (F5)

1), 2)

Clique com o botão direito do mouse no nome da solução

4), 5)

Alterar configuração para liberação

Espero que isso ajude você também.

Roshana Pitigala
fonte
5
  • Ir para: Solução -> Pacote
  • Clique na guia Avançado (encontre abaixo da página)
  • Adicione sua dll a assemblies adicionais (desta forma, podemos adicionar dlls externas no sharepoint).
Vijay Singh
fonte
7
Eu não tenho "Solução -> Package" no meu projeto VS2010
Muflix
5

Não tenho certeza se isso pode ajudar.

Verifique se o nome da montagem e o espaço para nome padrão nas propriedades em suas montagens combinam. Isso resolveu meu problema, que gerou o mesmo erro.

Sjaan
fonte
Excelente! Meu nome de arquivo DLL e o espaço para nome eram diferentes, copiei o espaço para nome e renomeei minha DLL.
Anynomous Khan 20/01
5

No meu caso, na pasta bin, havia uma dll sem referência chamada Unity.MVC3, tentei pesquisar qualquer referência a isso no visual studio sem sucesso, então minha solução foi tão fácil quanto excluir essa dll da pasta bin.

Totodile
fonte
4

Obrigado Riddhi M. Seguir trabalhou para mim.

Remover arquivos temporários C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Arquivos ASP.NET temporários Feche o VSTS e abra novamente Remova e adicione as mesmas DLLs (Observação: você adiciona as mesmas versões correspondentes)

Sridhar Kommana
fonte
Passei tanto tempo nisso e não acredito que essa foi a resposta. Geralmente, é uma boa solução quando você vê algum comportamento estranho no VS. Obrigado.
Bonez024
3

Você diz que tem muitos projetos em sua solução ... bem, comece com um próximo ao topo da ordem de construção. Faça com que esse seja construído e, depois que você descobrir, poderá aplicar a mesma correção ao restante deles.

Honestamente, você provavelmente só precisa atualizar sua referência. Parece que você atualizou sua versão e não atualizou as referências, ou é um problema de caminho relativo se você mantiver sua solução no controle de origem. Apenas verifique suas suposições e adicione novamente a referência.

Joel Martinez
fonte
3

A seguir funcionou para mim.

  • Remover arquivos temporários C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Arquivos ASP.NET temporários
    • clique com o botão direito do mouse em Arquivos temporários do Asp.net> propriedades> segurança e dê acesso total ao controle do IIS e de todos os usuários que executam meu projeto
só eu
fonte
3

Esse problema aconteceu comigo onde uma das minhas bibliotecas dependentes estava compilando uma DLL com "Qualquer CPU" quando a biblioteca pai esperava uma compilação de "x64".

Creamstout10
fonte
3

Eu tive o mesmo problema que eu resolvi através das instruções abaixo:

  1. abra o menu Ferramentas e selecione a opção
  2. em opções, janela vá para Projetos e soluções / Projetos da Web
  3. Verifica use the 64bit version of IIS ...

insira a descrição da imagem aqui

mohammad almasi
fonte
2

Você precisa excluir o arquivo appname.dll da pasta de saída. Limpe as pastas Debug e Release. Recrie e copie para o arquivo DLL regenerado da pasta de saída.

Gucci
fonte
2

I "Definir como projeto de inicialização" a biblioteca / projeto descarregado / não encontrado.

Então o implantei.

Funcionou!

Eu acho que não foi possível encontrar o .dll porque ele não estava na montagem a princípio.

nirav
fonte
2

Outra causa possível: verifique se você não atribuiu acidentalmente aos dois projetos o mesmo nome de montagem nas propriedades do projeto.

nathanchere
fonte
Isso me levou horas para descobrir .... eu acidentalmente chamado meu projeto de teste de unidade o mesmo nome que o projeto principal, de modo que o dll projeto de teste de unidade deve ter sido substituindo a dll projeto
Iannazzi
2

Minha solução para o .NET 4.0, usando a Enterprise Library 5, foi adicionar uma referência a:

Microsoft.Practices.Unity.Interception.dll

MacGyver
fonte
2

Procure referências conflitantes. Mesmo após uma limpeza e reconstrução, referências conflitantes ainda causarão um problema. Meu problema estava entre o AForge e o Accord. Eu removi as duas referências e as adicionei novamente, escolhendo novamente a referência específica (particular no meu caso, apenas Accord).

user3791372
fonte
2

Para mim, a reconstrução do jogo unity sem o Unity C # Proects Checkmark funcionou.

Praful Rudra
fonte
2

No meu caso, nenhuma das respostas propostas funcionou.

Aqui está o que funcionou para mim:

  1. Remova a referência
  2. Renomeie a DLL
  3. Importe a referência novamente

O segundo passo foi aparentemente importante, pois não funcionou sem ele.

Nicolas Raoul
fonte
2

Tente verificar se a propriedade "Copiar para local" da referência está definida como verdadeira e a versão específica está definida como verdadeira. Isso é relevante para aplicativos no Visual Studio.

Srinivas Somasundaram
fonte
2

Eu tinha isso hoje e, no meu caso, o problema era muito estranho:

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0" newVersion="3.1.0.0" />
  </dependentAssembly>0.

Observe os caracteres perdidos no final do XML - de alguma forma, eles foram movidos do número da versão para o final deste bloco de XML!

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0.0" newVersion="3.1.0.0" />
  </dependentAssembly>

Alterado para o acima e voila! Tudo funcionou novamente.

garryp
fonte
1

Se você estiver recebendo essa mensagem de erro ao abrir um aplicativo no Windows XP, significa que primeiro instalou o aplicativo devido ao fato de ele não funcionar sem o Net Framework 4 e o Service Pack 3. você instalou as duas vezes novamente e está recebendo este erro; portanto, você deve reinstalar o aplicativo novamente, mas primeiro desinstale e adicione e remova

se isso não funcionar, por favor não me abuse. eu também sou um júnior

basit durrani
fonte