Mensagem de erro ‘Não é possível carregar um ou mais dos tipos solicitados. Recupere a propriedade LoaderExceptions para mais informações. ‘

Eu desenvolvi um aplicativo usando Entity Framework , SQL Server 2000, Visual Studio 2008 e Enterprise Library.

Ele funciona perfeitamente bem localmente, mas quando eu implantar o projeto em nosso ambiente de teste, estou recebendo o seguinte erro:

Não é possível carregar um ou mais dos tipos solicitados. Recupere a propriedade LoaderExceptions para mais informações

Rastreio de pilha: em System.Reflection.Module._GetTypesInternal (StackCrawlMark & ​​stackMark)

em System.Reflection.Assembly.GetTypes ()

em System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadTypesFromAssembly (contexto LoadingContext)

em System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.InternalLoadAssemblyFromCache (Context LoadingContext)

em System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadAssemblyFromCache (Assembly assembly, loadReferencedAssemblies, Dictionary 2 knownAssemblies, Dictionary 2 & typesInLoading, List`1 e erros do Boolean)

em System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyFromCache (ObjectItemCollection objectItemCollection, Assembly assembly, loadReferencedAssemblies booleano)

em System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyForType (tipo de tipo)

em System.Data.Metadata.Edm.MetadataWorkspace.LoadAssemblyForType (tipo de tipo, assembly callingAssembly)

em System.Data.Objects.ObjectContext.CreateQuery [T] (String queryString, parâmetros ObjectParameter [])

Entity Framework parece ter problema, alguma pista de como consertá-lo?

Eu resolvi esse problema definindo o atributo Copy Local das referências do meu projeto como true.

Este erro não tem uma resposta mágica verdadeira. A chave é ter todas as informações para entender o problema. Muito provavelmente, um assembly carregado dinamicamente está faltando um assembly referenciado. Esse assembly precisa estar no diretório bin do seu aplicativo.

Use este código para determinar o que está faltando.

 using System.IO; using System.Reflection; using System.Text; try { //The code that causes the error goes here. } catch (ReflectionTypeLoadException ex) { StringBuilder sb = new StringBuilder(); foreach (Exception exSub in ex.LoaderExceptions) { sb.AppendLine(exSub.Message); FileNotFoundException exFileNotFound = exSub as FileNotFoundException; if (exFileNotFound != null) { if(!string.IsNullOrEmpty(exFileNotFound.FusionLog)) { sb.AppendLine("Fusion Log:"); sb.AppendLine(exFileNotFound.FusionLog); } } sb.AppendLine(); } string errorMessage = sb.ToString(); //Display or log the error based on your application. } 

Uma solução que funcionou para mim foi excluir as pastas bin / e obj / e reconstruir a solução.

Duas soluções possíveis:

  1. Você está compilando no modo Release, mas implantando uma versão compilada mais antiga do seu diretório Debug (ou vice-versa).
  2. Você não tem a versão correta do .NET Framework instalada em seu ambiente de teste.

Como foi mencionado anteriormente, geralmente é o caso de uma assembly que não está lá.

Para saber exatamente qual assembly está faltando, anexe seu depurador, defina um ponto de interrupção e, quando vir o object de exceção, faça um drill down até a propriedade ‘LoaderExceptions’. O conjunto ausente deve estar lá.

Espero que ajude!

Eu encontrei este erro com um aplicativo ASP.NET 4 + SQL Server 2008 R2 + Entity Framework 4.

Funcionaria bem na minha máquina de desenvolvimento (Windows Vista 64-bit). Em seguida, quando implantado no servidor ( Windows Server 2008 R2 SP1), funcionaria até que a session expirasse. Então, nós implantamos o aplicativo e tudo parecia bem e, em seguida, deixá-lo por mais do que o tempo limite de 20 minutos da session e, em seguida, esse erro seria lançado.

Para resolvê-lo, usei esse código no blog de Ken Cox para recuperar a propriedade LoaderExceptions.

Para minha situação, a DLL ausente era o Microsoft.ReportViewer.ProcessingObjectModel (versão 10). Essa DLL precisa ser instalada no GAC da máquina em que o aplicativo é executado. Você pode encontrá-lo no Pacote Redistribuível do Microsoft Report Viewer 2010, disponível no site de download da Microsoft.

Certifique-se de permitir aplicativos de 32 bits no IIS se você implantou no IIS. Você pode definir isso nas configurações do seu pool de aplicativos atual.

Se você estiver usando o EntityDataSource em seu projeto, a solução está no Corrigir: ‘Não é possível carregar um ou mais dos tipos solicitados’ Erros . Você deve definir o ContextTypeName = “ProjectNameNameSpace.EntityContainerName” ‘

Isso resolveu meus problemas …

Inicialmente eu tentei o visualizador de log do Fusion, mas isso não ajudou, então acabei usando o WinDbg com a extensão SOS.

! dumpheap -stat -type Exceção / D

Então eu examinei o FileNotFoundExceptions. A mensagem na exceção continha o nome da DLL que não estava sendo carregada.

NB, o / D fornece resultados com hiperlink, então clique no link no resumo para FileNotFoundException. Isso trará uma lista das exceções. Em seguida, clique no link para uma das exceções. Isso vai despejar exceções. Então você deve apenas clicar no link Message no object de exceção, e você verá o texto.

Outra solução para saber por que exatamente nada funciona (da Microsoft connect):

  1. Adicione este código ao projeto:

     foreach (var asm in AppDomain.CurrentDomain.GetAssemblies()) { asm.GetTypes(); } 
  2. Desativar os conjuntos de serialização de geração.

  3. Construa e execute.

A solução foi verificar o LoaderException: No meu caso, alguns dos arquivos DLL estavam faltando.

Digite a descrição da imagem aqui

Minha instância deste problema acabou sendo uma referência ausente. Um assembly foi referido no app.config, mas não tinha uma referência no projeto.

Adicionando o meu problema específico / solução para isso, pois este é o primeiro resultado para esta mensagem de erro. No meu caso, o erro foi recebido quando implantei um segundo aplicativo na pasta do meu primeiro aplicativo no IIS . Ambos estavam definindo a string de conexão com o mesmo nome, resultando no conflito do aplicativo filho e, por sua vez, gerando essa (para mim) mensagem de erro não óbvia. Foi resolvido adicionando:

  

no bloco de cadeia de conexão do aplicativo da web filho que impedia que ele herdasse as sequências de conexão de arquivos web.config mais altos na hierarquia, de modo que se parecesse com:

     

Uma questão de Stack Overflow de referência que ajudou, uma vez que eu determinei o que estava acontecendo, seria um aplicativo filho herdado de seu web.config pai? .

Isso funcionou para mim. Adicione no seu web.config

   

Eu tinha um .NET 4.0, ASP.NET MVC 2.0, aplicativo da web Entity Framework 4.0 desenvolvido no Visual Studio 2010. Eu tive o mesmo problema, que funcionava em um servidor Windows Server 2008 R2, mas não em outro servidor Windows Server 2008 R2, mesmo que as versões do .NET e do ASP.NET MVC fossem as mesmas, lançando este mesmo erro como o seu.

Eu fui seguir a sugestão do miko, então eu instalei o Windows SDK v7.1 (x64) no servidor com falha, assim eu pude rodar! Dumpheap.

Bem, acontece que a instalação do Windows SDK v7.1 (x64) resolveu o problema. Independentemente da falta de dependência, ela deve ter sido incluída no SDK. Pode ser baixado do Microsoft Windows SDK para Windows 7 e .NET Framework 4 .

Se você estiver usando o Entity Framework , tente copiar as seguintes referências localmente.

  • System.Data.Entity
  • System.Web.Entity

Altere a propriedade “Copy Local” para “True” para essas referências e publique.

Outras sugestões são todas boas. No meu caso, o problema era que a checkbox do desenvolvedor era uma máquina de 64 bits usando o local x86 de várias APIs, incluindo o Silverlight .

Ao alterar a plataforma de destino para corresponder ao servidor de 32 bits em que o aplicativo da Web estava sendo implantado, a maioria dos erros foi removida por não conseguir carregar um ou mais dos tipos solicitados.

Alterei a Propriedade de Versão Específica das Atualizações para false e isso ajudou.

Eu tive o mesmo problema (mas no meu local) quando eu estava tentando adicionar a migration do Entity Framework com o Console do Gerenciador de Pacotes.

A maneira como resolvi isso foi criando um aplicativo de console em que Main () tinha o seguinte código:

  var dbConfig = new Configuration(); var dbMigrator = new DbMigrator(dbConfig); dbMigrator.Update(); 

Certifique-se de que a class Configuration seja a Configuração de migration do seu projeto com falha. Você precisará de System.Data.Entity.Migrations para usar o DbMigrator.

Defina um ponto de interrupção em seu aplicativo e execute-o. A exceção deve ser capturada pelo Visual Studio (a menos que você tenha definido esse tipo de exceção para não interromper a session de debugging), e você deve conseguir encontrar as informações que está procurando.

A referência que faltava no meu caso era o EFProviderWrapperToolkit.

Eu tenho esse problema quando eu instalei um pacote NuGet em um dos projetos e esqueci de atualizar o outro projeto.

Eu resolvi isso apenas fazendo com que ambos os projetos tivessem a mesma assembly de referência.

Meu problema foi resolvido depois que eu apaguei os arquivos de assembly redundantes da pasta bin .

Caso nenhuma das outras respostas o ajude:

Quando tive esse problema, descobri que meu serviço do Windows foi criado para uma plataforma x64 e estava executando inadvertidamente a versão de 32 bits do InstallUtil.exe. Portanto, verifique se você está usando a versão correta do InstallUtil para a plataforma que você criou.

Defina o modo IIS de 32 bits como true, o modo de debugging como true no arquivo de configuração, excluindo o diretório temp e redefinindo o IIS corrige o problema temporariamente e ele volta depois de algum tempo.

Verifique se cada um dos seus projetos está configurado corretamente no Gerenciador de Configuração .

Semelhante ao motivo de William Edmondson para esse problema, eu mudei minha configuração do Configuration Manager de “Depurar” “Qualquer CPU” para “Depurar” “.NET”. O problema era que a versão “.NET” NÃO estava configurada para construir TODOS os projetos, então algumas de minhas DLLs estavam desatualizadas (enquanto outras eram atuais). Isso causou inúmeros problemas ao iniciar o aplicativo.

A solução temporária era fazer a sugestão de Kenny Eliasson de limpar os diretórios \ bin e \ obj. No entanto, assim que fiz mais alterações nos projetos não compilados, tudo falharia novamente.

Eu também tenho esse problema quando criar novo suplemento do Microsoft Word com o Visual Studio 2015. O problema é sobre eu tenho 2 versões do MS Office, 2013 e 2016. Eu desinstalo o MS Office 2013 e, em seguida, ele funciona.

Eu construo alguns projetos para o SharePoint e, claro, os implantei. Uma vez aconteceu.

Eu encontrei uma assembly antiga em C: \ Windows \ assembly \ temp \ xxx (com FarManager), removi-lo após a reboot e todos os projetos construídos.

Eu tenho pergunta para MSBuild, porque em assemblies de projeto vinculados como projetos e cada assembly está marcado “Copiar local”, mas não do GAC.

Eu tive a mesma mensagem de erro relatada ao compilar um pacote do Visual Studio (VSPackage). A solução inteira é compilada e o erro é lançado quando o pacote está sendo criado pelo CreatePkgDef. Dito isto, é claro que não posso pegar o LoaderExceptions, pois não é o meu aplicativo que o lança, mas a própria ferramenta da Microsoft. (Embora eu seja responsável pela confusão de CreatePkgDef.)

No meu caso, a causa raiz foi que minha solução cria um MyDll.dll que já foi registrado no GAC (e eles são diferentes), então o CreatePgkDef ficou confuso sobre qual deles usar e decidiu apenas lançar um erro que não é ‘ t realmente útil. O MyDll.dll no GAC foi registrado pelo instalador do mesmo produto (obviamente, uma versão anterior, com conteúdo / ligeiramente / diferente).

Como corrigi-lo

  1. Forma preferida: Certifique-se de usar a versão correta do MyDll.dll
    1. Ao compilar seu projeto, certifique-se de usar um número de versão diferente do usado na versão anterior localizada no GAC. Certifique-se de que os seguintes atributos estejam corretos:
      • [assembly: AssemblyVersion (“1.0.0.1”)] // Assumindo que o antigo arquivo DLL foi versionado 1.0.0.0
      • [assembly: AssemblyFileVersion (“1.0.0.1”)] // Supondo que o antigo arquivo DLL foi versionado 1.0.0.0
    2. Se necessário, especifique o nome completo do assembly (por exemplo, “MyDll.dll, Version = 1.0.0.1, Culture = neutral, PublicKeyToken = 1234567890abcdef”) ao fazer referência a ele em seus outros projetos.
  2. Se o acima falhou: Você pode desinstalar o antigo MyDll.dll do GAC
    1. Como desinstalar um assembly do GAC
    2. Desinstalar o aplicativo que inclui MyDll.dll

Alterar a AssemblyVersion foi bom o suficiente para mim. 🙂

Eu espero que isso tenha sido útil.

Eu posso corrigir esse problema marcando “Copy Local = True” em todos os arquivos DLL referenciados no projeto, reconstrução e implantação em um servidor de teste.

Eu tive um problema com o automap. Na pasta bin , o arquivo automap.4net.dll estava lá, mas por algum motivo o automap.xml e o automap.dll não estavam. Copiá-los para o diretório bin resolveu o problema.

Eu estava atualizando um site via FTP. Eu suponho que o site estava em uso e ao tentar atualizar a pasta bin, alguns dos arquivos DLL devem ter sido bloqueados e não foram atualizados.

Lá vi a página do erro 500 e na configuração do modo customErrors para Off, vi a mensagem de erro mencionada pelo OP.

O problema foi que eu não vi as falhas listadas no programa de FTP. Eu tentei novamente os que falharam e eles carregaram. O último arquivo DLL atualizado. Então o site funcionou.