System.BadImageFormatException: impossible de charger le fichier ou l'assembly (à partir de installutil.exe)

104

J'essaie d'installer un service Windows à l'aide d'InstallUtil.exe et j'obtiens le message d'erreur

System.BadImageFormatException: impossible de charger le fichier ou l'assembly ' {xxx.exe}' ou l'une de ses dépendances. Une tentative a été faite pour charger un programme avec un format incorrect.

Ce qui donne?


EDIT: (Pas par OP) Message complet extrait de dup obtenant beaucoup plus de hits [pour googleability]:

C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319> InstallUtil.exe C: \ xxx.exe Utilitaire d'installation de Microsoft (R) .NET Framework Version 4.0.30319.1 Copyright (c) Microsoft Corporation. Tous les droits sont réservés.

Une exception s'est produite lors de l'initialisation de l'installation: System.BadImageFormatException: impossible de charger le fichier ou l'assembly 'file: /// C: \ xxx.exe' ou l'une de ses dépendances. Une tentative de chargement d'un programme avec un format incorrect a été effectuée.

Epaga
la source

Réponses:

154

Quelques détails supplémentaires pour l'exhaustivité au cas où cela aiderait quelqu'un ...

Notez que la raison la plus courante de cette exception de nos jours est d'essayer de charger une /platform:x86DLL spécifique à 32 bits ( ) dans un processus 64 bits ou vice versa (à savoir charger une /platform:x64DLL spécifique à 64 bits ( ) dans un processus qui est 32 bits). Si votre platformn'est pas spécifique ( /platform:AnyCpu), cela ne se produira pas (en supposant qu'aucune dépendance référencée n'est du mauvais bitness).

En d'autres termes, exécuter:

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

ou:

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

ne fonctionnera pas (remplacez-le dans d'autres versions de framework: v1.1.4322(32 bits uniquement, donc ce problème ne se pose pas) et v4.0.30319comme souhaité dans ce qui précède).

Évidemment, comme indiqué dans l'autre réponse, il faudra également que le numéro de version .NET du que installutilvous exécutez soit> = (de préférence =) celui du fichier EXE / DLL dont vous exécutez le programme d'installation.

Enfin, notez que dans Visual Studio 2010, les outils généreront par défaut des binaires x86 ( plutôt que N'importe quel processeur comme précédemment ).

Détails complets de System.BadImageFormatException (dire que la seule cause est un manque de correspondance est vraiment une simplification excessive!).

Une autre raison pour un programme BadImageFormatExceptiond' installation sous un x64 est que dans Visual Studio 2010, le .vdprojtype de projet d'installation par défaut génère un InstallUtilLibshim 32 bits , même sur un système x64 (recherchez «les actions personnalisées gérées 64 bits lancent une exception System.BadImageFormatException» sur la page).

Ruben Bartelink
la source
J'ai eu le même problème, lorsque j'ai commencé le débogage selon ce que vous avez dit ci-dessus, j'ai trouvé que Platform: était défini sur x86. Quand je l'ai changé en n'importe quel processeur, cela a fonctionné :)
Atta H.
J'ai mon programme d'installation Windows avec des actions personnalisées. Ma configuration doit s'exécuter sur un système x64, donc les propriétés des actions personnalisées doivent cocher l'option "Run64Bit" sur true. Cela a résolu mon problème.
Hagen le
16

Assurez-vous que le plus récent Framework (celui avec lequel vous avez compilé votre application) est le premier dans le PATH. Cela a résolu le problème pour moi. (Trouvé sur un forum )

Epaga
la source
Ce lien semble avoir disparu. Pas trop surprenant cependant. Il y a 6 ans.
Al Lelopath
3
Le voici sur Archive.org web.archive.org/web/20100527204545/http
//www.issociate.de
9

Je pense que vous utilisez la version 64 bits de l'outil pour installer une application 32 bits. J'ai également fait face à ce problème aujourd'hui et j'ai utilisé ce chemin Framework pour répondre.

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

et il devrait installer votre application 32 bits très bien.

Sachin Kalia
la source
C'était le scénario pour moi. Réponse très utile.
Simos Fasouliotis
Au moins liez la réponse d'origine: stackoverflow.com/revisions/5229405/1
crusy
8

La clé est de définir les paramètres du processeur de correspondance pour le projet qui sont à deux endroits.

entrez la description de l'image ici

Et assurez-vous également que les paramètres d'architecture sont les mêmes dans le menu Test >> Paramètres de test >> Architecture du processeur par défaut >> comme indiqué ci-dessous.

entrez la description de l'image ici

C'est pour VS2013 mais peut-être même pour les autres versions aussi.

Mise à jour - Pour VS2019:

entrez la description de l'image ici

zar
la source
C'est la bonne façon de corriger cette erreur. Autrement dit, si vous ne voulez pas jouer avec des centaines de fichiers csproj.
Bizhan
6

OK, c'est le problème que j'ai eu, et ce qui l'a résolu semble très pertinent pour ce qui précède.

J'utilise Visual Studio 2010 Express. J'ai écrit un service de test qui n'a vraiment rien fait. C'était juste de la pratique pour la vraie chose plus tard.

J'ai écrit le service et essayé de l'installer en utilisant installutil.exeet j'ai obtenu l'erreur suivante:

System.BadImageFormatException: impossible de charger le fichier ou l'assembly '{filename.exe}' ou l'une de ses dépendances. Une tentative a été faite pour charger un programme avec un format incorrect.

Jusqu'à présent, le même que l'auteur original.

L'observation de Ruben ci-dessus à propos de la sortie 32 bits de Visual Studio 2010 a été le sauveur ici.

J'ai utilisé la version 64 bits de installutil.exeet bien sûr, la sortie de la version Visual Studio 2010 était 32 bits. Juste pour ajouter un peu de valeur supplémentaire ici, vous pouvez trouver la version 32 bits du dernier framework .NET et son associé installutil.exedans le dossier C: \ Windows \ Microsoft.NET \ framework . En utilisant cette version du installutil.execorrigé mon problème; le service installé sans accroc!

J'espère que cela aide quelqu'un d'autre là-bas.

James Crowther
la source
Je ne sais pas ce que vous entendez par la version 32 bits, mais j'ai essayé celle ici et cela n'a pas fonctionné non plus C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727
user2568374
3

Après avoir essayé toutes les solutions mentionnées, j'ai trouvé la configuration PlatformTargetajoutée d'une manière ou d'une autre AnyCPUdans mon projet .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>

La suppression de la ligne a fonctionné pour moi.

SohamC
la source
Dans mon cas, où je veux une version 64 bits, l'un des nœuds PropertyGroup manquait le nœud <PlatformTarget> x64 </PlatformTarget>, donc vraisemblablement il était par défaut sur 32 bits et lançait la mauvaise erreur de format d'image. Une fois que j'ai ajouté ce nœud manquant au groupe de propriétés, l'erreur a disparu.
Tom Regan
Essayer cette solution a conduit à un autre problème pour moi, à savoir que les appSettings de app.config n'étaient pas chargés pendant l'exécution malgré la présence du fichier de configuration dans le répertoire de sortie . cependant, après avoir essayé l'approche de zar ( Processor Architecture for AnyCPU Projects), tout recommence à fonctionner.
Bizhan
1

J'ai eu ce problème avec un projet WinForms utilisant VS 2015. Ma solution était:

  1. faites un clic droit sur le projet
  2. sélectionner des propriétés
  3. cochez "Préférer 32 bits"
  4. Cible de la plate-forme: tout processeur
Michael Staples
la source
0

J'ai eu le même problème. J'utilise la commande standard pour l'exécution. Il appelait le ro X64 exécuté contre les tests X86. J'avais besoin de spécifier le X86 et non la version X64 du nunit-runner.

dermot kirk
la source
0

En résumé, Build et Project \ Build \ Platform doivent être définis sur x64 pour pouvoir installer avec succès le service 64 bits sur un système 64 bits.

Daniel D
la source
0

Mon problème était différent. Cela s'est produit après un arrêt inattendu de ma machine Windows 7. J'ai effectué une solution propre et elle a fonctionné comme prévu.

GregN
la source
0

Dans le cas d'avoir ce message dans les tests en direct , mais pas dans les tests unitaires , c'est parce que les assemblys sélectionnés sont copiés à la volée vers $(SolutionDir)\.vs\$(SolutionName)\lut\0\0\x64\Debug\. Mais parfois, quelques assemblys ne peuvent pas être sélectionnés , par exemple, les DLL VC ++ dans le cas de projets d'interopérabilité c ++ / c #.

La post-compilation xcopyne résoudra pas le problème, car le fichier copié sera effacé par le moteur de test en direct.

La seule solution de contournement à ce jour (28 décembre 2018) est d'éviter les tests en direct et de tout faire dans les tests unitaires avec l'attribut [TestCategory("SkipWhenLiveUnitTesting")]appliqué à la classe de test ou à la méthode de test.

Ce bogue est observé dans n'importe quel Visual Studio 2017 jusqu'à 15.9.4 et doit être résolu par l'équipe Visual Studio.

Soleil - Mathieu Prévot
la source
0

Target build x64 Target Server Hosting IIS 64 Bit

Cliquez avec le bouton droit sur l'hébergement appPool exécutant le site Web / l'application Web et définissez l'activation de l'application 32 bits = false.

entrez la description de l'image ici

VK_217
la source
0

J'ai été confronté à ce problème aujourd'hui. Dans mon cas, la cible de plate-forme de mon application (avait une référence à une dll 64 bits) était définie sur AnyCPUmais la Prefer 32-bit case à cocher sous la section cible de la plate-forme était cochée par défaut. C'était le problème et tout fonctionnait bien après avoir décoché l' Prefer 32-bitoption.

cendre
la source
0

Nous avons trouvé une solution différente à un problème avec le même symptôme:

Nous avons vu cette erreur lorsque nous avons mis à jour le projet de .net 4.7.1 à 4.7.2.

Le problème était que même si nous ne référenions plus System.Net.Http dans le projet, il était répertorié dans la section dependAssembily de notre web.config. La suppression de cette référence et de toute autre référence d'assembly inutilisée du web.config a résolu le problème.

Logan
la source
0

Le problème est que tous, System.BadImageFormatException: Could not load file or assemblyy compris ceux qui ne sont pas du tout associés, installutil.exepointent vers ce fil.

  1. Si votre problème est lié à WindowsBaseou aux PresentationFramework dll et que des analyseurs sont installés, assurez-vous de les avoir installés pour tous les projets de votre solution ou pour aucun d'entre eux.

    entrez la description de l'image ici

  2. Référencez l'ensemble du framework dans le .csprojfichier de votre bibliothèque plutôt que les deux dlls:

    <Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
    
      <PropertyGroup>
        <OutputType>Library</OutputType>
        <TargetFramework>netcoreapp3.0</TargetFramework>
        <RazorLangVersion>3.0</RazorLangVersion>
        <UseWpf>True</UseWpf>
      </PropertyGroup>
  3. Supprimer binet objrépéter, nettoyer la solution et reconstruire.

rvnlord
la source