Solução de problemas BadImageFormatException

Eu tenho um serviço do Windows escrito em C # usando o Visual Studio 2010 e visando o .NET Framework 4. Quando executo de uma compilation de debugging, o serviço é executado conforme o esperado. No entanto, quando eu corri-lo de uma compilation de lançamento, recebo um System.BadImageFormatException (detalhes abaixo). Eu tenho procurado na internet por uma solução, mas até agora cada coisa que encontrei não me ajudou a encontrar uma solução.

O problema existe em sistemas Windows 7 de 64 bits (dev) e Windows XP SP3 de 32 bits (destino).

Aqui está o que eu tentei até agora:

  • As configurações de criação verificadas, como o Platform Target, são todas iguais (x86).
  • Usado peverify com a opção / verbose para garantir que os binários de assembly sejam válidos.
  • Usa fuslogvw para procurar por qualquer problema de carregamento.
  • Usei o CheckAsm para procurar arquivos ou montagens ausentes.

Todas essas verificações não mudaram nada. Eu incluí o texto completo das informações de exceção abaixo, com alguns dos nomes alterados para proteger os segredos dos meus mestres corporativos.

 System.BadImageFormatException foi manipulado
   Mensagem = Não foi possível carregar o arquivo ou assembly 'XxxDevices, Versão = 1.0.0.0, Culture = neutral, PublicKeyToken = null' ou uma de suas dependencies.  Foi feita uma tentativa de carregar um programa com um formato incorreto.
   Fonte = XxxDevicesService
   FileName = XxxDevices, versão = 1.0.0.0, Culture = neutral, PublicKeyToken = null
   FusionLog = Gerenciador de assembly carregado de: C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ clr.dll
 Executando sob executável c: \ Dev \ TeamE \ bin \ Release \ XxxDevicesService.vshost.exe
 --- Um log de erro detalhado segue. 

 === Pré-vincular informações de estado ===
 LOG: usuário = XXX
 LOG: DisplayName = XxxDevices, versão = 1.0.0.0, Culture = neutral, PublicKeyToken = null
  (Totalmente especificado)
 LOG: Appbase = arquivo: /// c: / Dev / TeamE / bin / Release /
 LOG: Initial PrivatePath = NULL
 Chamando assembly: XxxDevicesService, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null.
 ===
 LOG: Esta binding inicia no contexto de carregamento padrão.
 LOG: Usando o arquivo de configuração do aplicativo: c: \ TeamE \ bin \ Release \ XxxDevicesService.vshost.exe.Config
 LOG: Usando o arquivo de configuração do host: 
 LOG: Usando o arquivo de configuração da máquina em C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ config \ machine.config.
 LOG: Política que não está sendo aplicada à referência neste momento (associação de assembly privada, personalizada, parcial ou baseada em localização).
 LOG: Tentativa de download do novo arquivo de URL: /// c: /TeamE/bin/Release/XxxDevices.DLL.
 ERRO: falha ao concluir a instalação da assembly (hr = 0x8007000b).  Sondagem terminada.

   StackTrace:
        em XxxDevicesService.Program.Main (String [] args)
        em System.AppDomain._nExecuteAssembly (assembly RuntimeAssembly, String [] args)
        em Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly ()
        em System.Threading.ExecutionContext.Run (ExecutionContext executionContext, retorno de chamada de ContextCallback, estado do object, Boolean ignoreSyncCtx)
        em System.Threading.ExecutionContext.Run (ExecutionContext executionContext, retorno de chamada de ContextCallback, estado do object)
        em System.Threading.ThreadHelper.ThreadStart ()
   InnerException: 

As configurações de criação verificadas, como o Platform Target, são todas iguais (x86).

Não é isso que o log de falhas diz:

Gerenciador de assembly carregado de: C: \ Windows \ Microsoft.NET \ Framework64

Observe o 64 no nome, que é o lar da versão de 64 bits do framework. Defina a configuração de plataforma de destino em seu projeto EXE , não seu projeto de biblioteca de classs. O projeto XxxDevicesService EXE determina o bitness do processo.

Depois que eu parei de bater a cabeça na mesa pensando em toda a semana que passei correndo esse problema, estou compartilhando o que funcionou para mim. Eu tenho o Win7 de 64 bits, 32-bit Oracle Client, e tenho o meu projeto de MVC 5 configurado para rodar na plataforma x86 por causa do bitness do Oracle. Eu continuei recebendo os mesmos erros:

Não foi possível carregar o arquivo ou assembly ‘Oracle.DataAccess’ ou uma de suas dependencies. Foi feita uma tentativa de carregar um programa com um formato incorreto.

Eu recarreguei os pacotes NuGet, usei cópias das DLLs que funcionavam para outras pessoas em aplicativos diferentes, configurei a base de código no assembly dependente para apontar para a pasta bin do meu projeto, tentei CopyLocal como true ou false, tentei tudo. Finalmente eu tive o suficiente para fazer o check-in do meu código, e como um novo contratado eu não tinha o subversion configurado. Enquanto procurava uma maneira de ligá-lo ao VS, tropecei na resposta. O que eu encontrei funcionou foi desmarcar a opção “Usar a versão de 64 bits do IIS Express para Sites e Projetos” na seção Projetos e Soluções => Projetos da Web no menu Ferramentas => Opções.

Normalmente, isso pode ocorrer quando você altera a estrutura de destino de .csproj e a reverta de volta para o que você iniciou.

Certifique-se 1 se supportedRuntime version = “um tempo de execução diferente do cs project target” na tag de boot no app.config.

Certifique-se de 2 Isso também significa verificar outros arquivos autogerados ou outros arquivos em pode ser a pasta de propriedades para ver se não há mais incompatibilidade de tempo de execução entre esses arquivos e um que é definido no arquivo .csproj.

Isso pode poupar muito tempo antes de você começar a tentar coisas diferentes com as propriedades do projeto para superar o erro.

O que eu encontrei funcionou foi verificar a opção “Usar a versão de 64 bits do IIS Express para Sites e Projetos” na seção Projetos e Soluções => Projetos da Web no menu Ferramentas => Opções.

Eu tive o mesmo problema, mesmo que eu tenha o Windows 7 de 64 bits e eu estava carregando uma DLL de 64 bits b / c em propriedades do projeto | Compilação eu tinha “Prefer 32-bit” verificada. (Não sei por que isso é definido por padrão). Uma vez desmarcada, tudo correu bem

Você também pode obter essa exceção quando seu aplicativo estiver destinado ao .NET Framework 4.5 (por exemplo) e você tiver o seguinte app.config:

 < ?xml version="1.0" encoding="utf-8"?>       

Ao tentar iniciar a debugging do aplicativo, você obterá o BadImageFormatException.

Remover a linha que declara a versão v2.0 limpará o erro.

Eu tive esse problema recentemente quando tentei alterar a plataforma de destino de um projeto .NET 2.0 antigo para o .NET 4.5.

fundo

Começamos a receber isso hoje quando trocamos nosso serviço WCF de AnyCPU para x64 em um servidor Windows 2012 R2 executando o IIS 6.2.

Primeiro, verificamos o único assembly referenciado 10 vezes, para garantir que ele não era realmente um x86 dll. Em seguida, verificamos o pool de aplicativos várias vezes para garantir que ele não estava habilitando aplicativos de 32 bits.

Por um capricho, tentei mudar o cenário. Acontece que os pools de aplicativos no IIS foram padronizados para um valor de Ativar Aplicativos de 32 Bits como Falso, mas o IIS o estava ignorando em nosso servidor por algum motivo e sempre executava nosso serviço no modo x86.

Solução

  • Selecione o pool de aplicativos.
  • Escolha Definir Padrões do Pool de Aplicativos … ou Configurações Avançadas ….
  • Alterar ativar aplicativos de 32 bits para True.
  • Clique em OK
  • Escolha Definir Padrões do Pool de Aplicativos … ou Configurações Avançadas … novamente.
  • Altere Ativar Aplicativos de 32 Bits de volta para Falso.
  • Clique em OK

Corrigi esse problema alterando o aplicativo da Web para usar um “Pool de aplicativos” diferente.

Para quem pode chegar aqui mais tarde … Nada funcionou para mim. Todas as minhas assembleias estavam bem. Eu tinha uma configuração de aplicativo em um dos meus projetos do Visual Studio que não deveria estar lá. Portanto, verifique se o arquivo de configuração do aplicativo é necessário.

Eu deletei a configuração extra do aplicativo e funcionou.

Determine o pool de aplicativos usado pelo aplicativo e defina a propriedade de configurando Ativar aplicativos de 32 bits como True. Isso pode ser feito por meio de configurações avançadas do pool de aplicativos.

Ao criar aplicativos para plataformas de 32 ou 64 bits (Minha experiência é com o Visual Studio 2010), não confie no Gerenciador de Configurações para definir a plataforma correta para o executável. Mesmo se o CM tiver x86 selecionado para o aplicativo, verifique as propriedades do projeto (guia Build): ele ainda pode dizer “Any CPU” (qualquer CPU). E se você executar um executável “Qualquer CPU” em uma plataforma de 64 bits, ele será executado no modo de 64 bits e se recusará a carregar as DLLs que o acompanham que foram criadas para a plataforma x86.

Para quem pode chegar aqui mais tarde …
Para a solução Desktop, recebi a exceção BadImageFormatException .
Todas as opções de construção do projeto estavam bem (todas x86 ). Mas o projeto de solução StartUp foi alterado para outro projeto (projeto de biblioteca de classs).

Alterar o projeto StartUp para o original (.exe application project) foi uma solução no meu caso

Quando enfrentei este problema, o seguinte resolveu para mim:

Eu estava chamando uma dll OpenCV de dentro de outro exe, minha dll não continha as dlls opencv já necessários como highgui, features2d e etc disponíveis na pasta do meu arquivo exe. Eu copiei todos estes para o diretório do meu projeto exe e de repente funcionou.

Remova sua dependência do System.Runtime no seu Web.Config, funcionou para mim:

     

Este erro “Não foi possível carregar o arquivo ou assembly ‘exemplo’ ou uma de suas dependencies. Foi feita uma tentativa de carregar um programa com um formato incorreto” geralmente é causada por uma configuração incorreta do pool de aplicativos.

  1. Certifique-se de que o AppPool em que seu site está sendo executado tenha “Ativar aplicativos de 32 bits” definido como Falso.
  2. Verifique se você está usando a versão correta para sua plataforma.
  3. Se você estiver recebendo este erro em um site, verifique se o pool de aplicativos está configurado para ser executado no modo correto (sites 3.0 devem ser executados no modo de 64 bits)
  4. Você também deve se certificar de que a referência a essa assembly no visual studio esteja apontando para o arquivo correto na pasta packages.
  5. Certifique-se de ter a versão correta da dll instalada no GAC para sites 2.0.
  6. Isso também pode ser causado pelo WSODLibs sendo promovido com o projeto da web.

Para o .NET Core , há um erro do Visual Studio 2017 que pode fazer com que a página Build das propriedades do projeto mostre o destino incorreto da plataforma. Depois de descobrir que o problema é, as soluções são bem fáceis. Você pode alterar o alvo para algum outro valor e depois alterá-lo de volta.

Como alternativa, você pode adicionar um identificador de tempo de execução ao .csproj. Se você precisar que seu .exe seja executado como x86 para que possa carregar uma DLL nativa x86, adicione esse elemento em um PropertyGroup :

 win-x86 

Um bom lugar para colocar isso é logo após o elemento TargetFrameworks ou TargetFrameworks .