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

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.

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

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.

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.

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

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!

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.

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)

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.

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:

No 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".

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:

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?

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)

4), 5)

Espero que isso ajude você também.

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

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.

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.

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)

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.

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

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

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

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.

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.

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

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

Microsoft.Practices.Unity.Interception.dll

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

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

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.

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.

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.

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