c# - uma - não foi possível carregar arquivo ou assembly system io compression




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

  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.dll que precisa de uma versão antiga do assembly Unity. Agora, quando fizer referência ao ServiceLocator , forneça a versão antiga do Unity e isso será 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, apenas definir um caminho para o log e executar sua solução e, em seguida, verificar (no FusLogvw) a primeira linha onde o assembly Unity está carregado, clique duas vezes nele e veja a chamada montagem, e aqui vai você.

Estou tendo outro desses problemas "Não foi possível carregar o arquivo ou o assembly ou um de suas dependências".

Informações adicionais: Não foi possível carregar o arquivo ou assembly 'Microsoft.Practices.Unity, Version = 1.2.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35' ou uma de suas dependências. A definição de manifesto do assembly localizado não corresponde à referência de assembly. (Exceção de HRESULT: 0x80131040)

Eu não tenho ideia do que está causando isso ou como eu poderia depurá-lo para encontrar a causa.

Eu fiz uma pesquisa nos meus catálogos de soluções, arquivos .csproj, e em todos os lugares que eu tenho, eu tenho:

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

Não é possível encontrar qualquer referência em qualquer lugar que seja contra o 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.


A Microsoft Enterprise Library (referenciada por .NetTiers) foi o nosso problema, que por sua vez referenciava 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 querer apenas atualizar a Biblioteca Corporativa para a versão mais recente.


A seguir funcionou para mim.

  • Remover arquivos temporários do C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET
    • em seguida, clique com o botão direito do mouse em Temporary Asp.net Files> properties> security e dê total controle de acesso ao IIS e a todos os usuários que executam meu projeto

Apesar da pergunta original ter sido postada há 5 anos, o problema ainda persiste e é bastante irritante.

A solução geral é uma análise completa de todos os conjuntos referenciados para entender o que está errado. Para facilitar essa tarefa, criei uma ferramenta (uma extensão do Visual Studio) que permite selecionar um assembly .Net (arquivo .ddl ou .exe) e obter um gráfico de todos os assemblies referenciados com referências conflitantes ou perdidas realçadas.

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

Exemplo de saída:


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


Eu "Defina como Projeto de Inicialização" a biblioteca / projeto não carregado / não encontrado.

Em seguida, implantou.

Funcionou!

Eu acho que não foi possível encontrar o .dll porque não estava na montagem no início.


Eu tive 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, esses foram movidos do número da versão para o final desse 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.


Eu tive problema semelhante. ** Juntos resposta está correta ** mas você deve notar uma dica importante!

Para a unidade 2.1.505.2, AssemblyVersion e AssemblyFileVersion diferentes são especificados:

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

Portanto, os redirecionamentos devem ser aplicados a uma versão especificada em AssemblyVersion: 2.1.505.0

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

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


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

Microsoft.Practices.Unity.Interception.dll


Não tenho certeza se isso pode ajudar.

Verifique se o nome do Assembly e o namespace Default nas correspondências Properies in as asuplies. Isso resolveu meu problema, que produziu o mesmo erro.


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.


Obrigado Riddhi M. A 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)


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


Para mim, nenhuma das outras soluções funcionou (incluindo a estratégia de limpeza / reconstrução). Eu 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 em sua solução. Em seguida, remova e adicione a unidade novamente.


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


Verifique o arquivo Web.config / App.config em 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.


Você diz que tem muitos projetos em sua solução ... bem, comece com um próximo ao topo da ordem de construção. Consiga aquele para construir e uma vez que você descobrir, você pode aplicar a mesma correção para o resto 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.


No solucionador de soluções, clique com o botão direito do mouse no projeto (não na solução), na aba Build, selecione Platform target: "Any CPU".


Abra o Gerenciador do IIS

Selecione pools de aplicativos

em seguida, selecione o pool que você está usando

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

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





compiler-errors