System.BadImageFormatException: Não foi possível carregar o arquivo ou montagem (de installutil.exe)

Estou tentando instalar um serviço do Windows usando InstallUtil.exe e estou recebendo a mensagem de erro

System.BadImageFormatException: Não foi possível carregar o arquivo ou assembly ' {xxx.exe}' ou uma de suas dependências. Foi feita uma tentativa de carregar um programa com um formato incorreto.

O que da?

EDITAR: (Não por OP) Mensagem completa extraída de dup obtendo muito mais ocorrências [para googleability]:

C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319> InstallUtil.exe C: \ xxx.exe Utilitário de instalação do Microsoft (R) .NET Framework Versão 4.0.30319.1 Copyright (c) Microsoft Corporation. Todos os direitos reservados.

Ocorreu uma exceção ao inicializar a instalação: System.BadImageFormatException: Não foi possível carregar o arquivo ou assembly 'file: /// C: \ xxx.exe' ou uma de suas dependências. Foi feita uma tentativa de carregar um programa com um formato incorreto.

Mais alguns detalhes para completar, caso ajude alguém ...

Observe que o motivo mais comum para essa exceção hoje em dia é a tentativa de carregar uma /platform:x86DLL específica de 32 bits ( ) em um processo de 64 bits ou vice-versa (ou seja, carregar uma /platform:x64DLL específica de 64 bits ( ) em um processo que é 32 bits). Se o seu platformfor não específico ( /platform:AnyCpu), isso não ocorrerá (assumindo que nenhuma dependência referenciada seja do bit errado).

Em outras palavras, executando:

% windir% \ Microsoft.NET \ Framework \ v2.0.50727 \ installutil.exe

ou:

% windir% \ Microsoft.NET \ Framework 64 \ v2.0.50727 \ installutil.exe

não funcionará (substitua em outras versões do framework: v1.1.4322(apenas 32 bits, portanto, esse problema não surge) e v4.0.30319conforme desejado acima).

Obviamente, conforme abordado na outra resposta, também será necessário que o número da versão .NET do que installutilvocê está executando seja> = (de preferência =) do arquivo EXE / DLL do qual está executando o instalador.

Finalmente, observe que no Visual Studio 2010, o conjunto de ferramentas será padronizado para gerar binários x86 (em vez de Qualquer CPU, como anteriormente ).

Detalhes completos de System.BadImageFormatException (dizer que a única causa é bittedness incompatível é realmente uma simplificação grosseira!).

Outro motivo para um instalador BadImageFormatExceptionem um x64 é que no Visual Studio 2010, o .vdprojtipo de projeto de instalação padrão gera um InstallUtilLibshim de 32 bits , mesmo em um sistema x64 (pesquise por "ações personalizadas gerenciadas de 64 bits lançam uma exceção System.BadImageFormatException" em a página).

Certifique-se de que o Framework mais recente (aquele com o qual você compilou seu aplicativo) esteja primeiro no PATH. Isso resolveu o problema para mim. (Encontrado em um fórum )

Acho que você está usando a versão de 64 bits da ferramenta para instalar um aplicativo de 32 bits. Também enfrentei esse problema hoje e usei esse caminho do Framework para atender.

C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319

e deve instalar seu aplicativo de 32 bits perfeitamente.

A chave é definir as configurações de processador correspondentes para o projeto, que estão em dois lugares.

E também certifique-se de que as configurações de arquitetura sejam as mesmas no menu Test >> Test Settings >> Default Processor Architecture >> conforme mostrado abaixo.

Isso é para VS2013, mas talvez o mesmo para outras versões também.

Atualização - Para VS2019:

OK, este é o problema que tive e, o que o corrigiu, parece muito relevante para o anterior.

Estou usando o Visual Studio 2010 Express. Eu escrevi um serviço de teste que realmente não fazia nada. Era apenas prática para a coisa real mais tarde.

Escrevi o serviço e tentei instalá-lo usando installutil.exee obtive o seguinte erro:

System.BadImageFormatException: Não foi possível carregar o arquivo ou assembly '{filename.exe}' ou uma de suas dependências. Foi feita uma tentativa de carregar um programa com um formato incorreto.

Até agora igual ao autor original.

A observação de Ruben acima sobre a saída de 32 bits do Visual Studio 2010 foi a salvadora aqui.

Usei a versão de 64 bits do installutil.exee, com certeza, a saída da compilação do Visual Studio 2010 foi de 32 bits. Apenas para adicionar um valor extra aqui, você pode encontrar a versão de 32 bits do framework .NET mais recente e o associado installutil.exena pasta C: \ Windows \ Microsoft.NET \ framework . Usar esta versão do installutil.execorrigiu meu problema; o serviço instalado sem problemas!

Espero que isso ajude alguém por aí.

Depois de tentar todas as soluções mencionadas, encontrei o de PlatformTargetalguma forma adicionado à AnyCPUconfiguração no meu projeto .csproj.

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <PlatformTarget>x64</PlatformTarget>
</PropertyGroup>

Remover a linha funcionou para mim.

Tive esse problema com um projeto WinForms usando o VS 2015. Minha solução foi:

1. clique com o botão direito no projeto
2. selecione propriedades
3. marque "Preferir 32 bits"
4. Alvo da plataforma: qualquer CPU

Eu tive o mesmo problema. Estou usando o comando padrão para execução. Ele estava chamando o X64 ro para rodar contra os testes do X86. Eu precisava especificar o X86 e não a versão X64 do nunit-runner.

Resumindo, tanto o Build quanto o Project \ Build \ Platform devem ser definidos como x64 para instalar com êxito o serviço de 64 bits no sistema de 64 bits.

Meu problema era diferente. Isso ocorreu após um desligamento inesperado da minha máquina com Windows 7. Executei uma solução limpa e funcionou conforme o esperado.

No caso de ter essa mensagem em testes ativos , mas não em testes de unidade , é porque os assemblies selecionados são copiados em tempo real $(SolutionDir)\.vs\$(SolutionName)\lut\0\0\x64\Debug\. Mas às vezes alguns assemblies podem não ser selecionados , por exemplo, dlls VC ++ no caso de projetos interoperáveis ​​c ++ / c #.

A pós-compilação xcopynão corrigirá o problema, porque o arquivo copiado será apagado pelo mecanismo de teste ao vivo.

A única solução até o momento (28 de dezembro de 2018) é evitar os testes Live e fazer tudo em testes de unidade com o atributo [TestCategory("SkipWhenLiveUnitTesting")]aplicado à classe de teste ou ao método de teste.

Esse bug é visto em qualquer Visual Studio 2017 até 15.9.4 e precisa ser corrigido pela equipe do Visual Studio.

Versão de destino x64 Servidor de destino Hospedando IIS de 64 bits

Clique com o botão direito do mouse em appPool que hospeda o site / aplicativo da web e defina a ativação do aplicativo de 32 bits = false.

Eu enfrentei esse problema hoje. No meu caso, o destino da plataforma do meu aplicativo (tinha uma referência a uma dll de 64 bits) foi definido como, AnyCPUmas a Prefer 32-bit caixa de seleção na seção de destino da plataforma estava marcada por padrão. Este era o problema e funcionou bem após desmarcar a Prefer 32-bitopção.

Encontramos uma solução diferente para um problema com o mesmo sintoma:

Vimos esse erro quando atualizamos o projeto .net 4.7.1 para 4.7.2.

O problema era que, embora não estivéssemos mais fazendo referência a System.Net.Http no projeto, ele estava listado na seção associatedAssembily de nosso web.config. A remoção desta e de quaisquer outras referências de assembly não utilizadas do web.config resolveu o problema.

O problema é que todos, System.BadImageFormatException: Could not load file or assemblyincluindo aqueles não associados installutil.exe, apontam para este mesmo tópico.

1. Se o seu problema estiver relacionado a WindowsBaseou PresentationFramework dlls e você tiver analisadores instalados, certifique-se de instalá-los para todos os projetos em sua solução ou para nenhum deles.

   

2. Faça referência a toda a estrutura no .csprojarquivo de sua biblioteca, em vez de apenas os dois dlls:

   <Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
   
     <PropertyGroup>
       <OutputType>Library</OutputType>
       <TargetFramework>netcoreapp3.0</TargetFramework>
       <RazorLangVersion>3.0</RazorLangVersion>
       <UseWpf>True</UseWpf>
     </PropertyGroup>

3. Remova bine objdirs, limpe a solução e reconstrua.