Dépannage de BadImageFormatException

J'ai un service Windows écrit en C # à l'aide de Visual Studio 2010 et ciblant le .NET Framework complet 4. Lorsque je cours à partir d'un débogage, le service s'exécute comme prévu. Cependant, lorsque je l'exécute à partir d'une version Release, j'obtiens une System.BadImageFormatException (détails ci-dessous). J'ai cherché une solution sur Internet, mais jusqu'à présent, tout ce que j'ai trouvé ne m'a pas aidé à trouver une solution.

Le problème existe sur les systèmes Windows 7 64 bits (dev) et Windows XP SP3 32 bits (cible).

Voici ce que j'ai essayé jusqu'à présent:

• Les paramètres de construction vérifiés tels que Platform Target sont tous les mêmes (x86).
• Utilisé peverify avec l'option / verbose pour s'assurer que les binaires d'assembly étaient valides.
• Utilise fuslogvw pour rechercher tout problème de chargement.
• Utilisé CheckAsm pour rechercher des fichiers ou des assemblages manquants.

Tous ces contrôles n'ont rien changé. J'ai inclus le texte intégral des informations d'exception ci-dessous, avec certains des noms modifiés pour protéger les secrets de mes chefs d'entreprise.

System.BadImageFormatException n'a pas été gérée
  Message = Impossible de charger le fichier ou l'assembly 'XxxDevices, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null' ou l'une de ses dépendances. Une tentative a été faite pour charger un programme avec un format incorrect.
  Source = XxxDevicesService
  FileName = XxxDevices, Version = 1.0.0.0, Culture = neutre, PublicKeyToken = null
  FusionLog = Gestionnaire d'assemblage chargé depuis: C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ clr.dll
Exécution sous l'exécutable c: \ Dev \ TeamE \ bin \ Release \ XxxDevicesService.vshost.exe
--- Un journal d'erreurs détaillé suit. 

=== Informations sur l'état de pré-liaison ===
LOG: Utilisateur = XXX
JOURNAL: DisplayName = XxxDevices, Version = 1.0.0.0, Culture = neutre, PublicKeyToken = null
 (Entièrement spécifié)
LOG: Appbase = fichier: /// c: / Dev / TeamE / bin / Release /
JOURNAL: Chemin privé initial = NULL
Appel de l'assembly: XxxDevicesService, Version = 1.0.0.0, Culture = neutre, PublicKeyToken = null.
===
LOG: Cette liaison démarre dans le contexte de chargement par défaut.
LOG: Utilisation du fichier de configuration de l'application: c: \ TeamE \ bin \ Release \ XxxDevicesService.vshost.exe.Config
LOG: Utilisation du fichier de configuration d'hôte: 
LOG: Utilisation du fichier de configuration de la machine à partir de C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ config \ machine.config.
LOG: la stratégie n'est pas appliquée à la référence pour le moment (liaison d'assembly privée, personnalisée, partielle ou basée sur l'emplacement).
LOG: tentative de téléchargement du nouveau fichier URL: /// c: /TeamE/bin/Release/XxxDevices.DLL.
ERR: échec de la configuration de l'assemblage (hr = 0x8007000b). Le sondage est terminé.

  Trace de la pile:
       à XxxDevicesService.Program.Main (String [] args)
       à System.AppDomain._nExecuteAssembly (assembly RuntimeAssembly, String [] args)
       à Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly ()
       à System.Threading.ExecutionContext.Run (ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
       à System.Threading.ExecutionContext.Run (ExecutionContext executionContext, rappel de ContextCallback, état de l'objet)
       à System.Threading.ThreadHelper.ThreadStart ()
  InnerException: 

Les paramètres de construction vérifiés tels que Platform Target sont tous les mêmes (x86).

Ce n'est pas ce que dit le journal des plantages:

Gestionnaire d'assemblage chargé à partir de: C: \ Windows \ Microsoft.NET \ Framework64

Notez le 64 dans le nom, c'est la maison de la version 64 bits du framework. Définissez le paramètre de plate-forme cible sur votre projet EXE , pas sur votre projet de bibliothèque de classes. Le projet EXE XxxDevicesService détermine le bitness du processus.

Après avoir arrêté de me cogner la tête sur le bureau en pensant à toute la semaine que j'ai passée à résoudre ce problème, je partage ce qui a fonctionné pour moi. J'ai Win7 64 bits, client Oracle 32 bits, et mon projet MVC 5 est configuré pour fonctionner sur la plate-forme x86 en raison du bitness Oracle. J'ai continué à recevoir les mêmes erreurs:

Impossible de charger le fichier ou l'assembly 'Oracle.DataAccess' ou l'une de ses dépendances. Une tentative a été faite pour charger un programme avec un format incorrect.

J'ai rechargé les packages NuGet, j'ai utilisé des copies des DLL qui fonctionnaient pour d'autres dans différentes applications, j'ai défini la base de code dans l'assemblage dépendant pour qu'elle pointe vers le dossier bin de mon projet, j'ai essayé CopyLocal comme vrai ou faux, j'ai tout essayé . Finalement, j'en avais assez d'autre, je voulais vérifier mon code, et en tant que nouvel entrepreneur, je n'avais pas installé de subversion. En cherchant un moyen de le connecter à VS, j'ai trébuché sur la réponse. Ce que j'ai trouvé a fonctionné était de décocher l'option «Utiliser la version 64 bits d'IIS Express pour les sites Web et les projets» sous la section Projets et solutions => Projets Web sous le menu Outils => Options.

Ce que j'ai trouvé a fonctionné était de vérifier l'option «Utiliser la version 64 bits d'IIS Express pour les sites Web et les projets» sous la section Projets et solutions => Projets Web sous le menu Outils => Options.

Cela peut généralement se produire lorsque vous avez modifié le cadre cible de .csproj et que vous l'avez rétabli à ce que vous aviez commencé.

Assurez-vous que 1 si supportedRuntime version = "un runtime différent de la cible du projet cs" sous la balise de démarrage dans app.config.

Assurez-vous que 2 Cela signifie également vérifier d'autres fichiers générés automatiquement ou d'autres dans le dossier de propriétés peut-être pour voir s'il n'y a plus d'incohérence d'exécution entre ces fichiers et celui qui est défini dans le fichier .csproj.

Celles-ci pourraient vous faire gagner beaucoup de temps avant de commencer à essayer différentes choses avec les propriétés du projet pour surmonter l'erreur.

J'ai eu le même problème même si j'ai Windows 7 64 bits et que je chargeais une DLL 64 bits b / c dans les propriétés du projet | Build J'ai fait cocher "Préférer 32 bits". (Je ne sais pas pourquoi c'est défini par défaut). Une fois que j'ai décoché ça, tout s'est bien passé

Vous pouvez également obtenir cette exception lorsque votre application cible .NET Framework 4.5 (par exemple) et que vous disposez du fichier app.config suivant:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup>
    <supportedRuntime version="v2.0.50727" />
    <supportedRuntime version="v4.0" />
  </startup>
</configuration>

Lorsque vous essayez de lancer le débogage de l'application, vous obtiendrez l'exception BadImageFormatException.

La suppression de la ligne déclarant la version v2.0 effacera l'erreur.

J'ai eu ce problème récemment lorsque j'ai essayé de changer la plate-forme cible d'un ancien projet .NET 2.0 vers .NET 4.5.

Contexte

Nous avons commencé à l'obtenir aujourd'hui lorsque nous avons fait passer notre service WCF d'AnyCPU à x64 sur un serveur Windows 2012 R2 exécutant IIS 6.2.

Nous avons d'abord vérifié 10 fois le seul assembly référencé, pour nous assurer qu'il ne s'agissait pas réellement d'une dll x86. Ensuite, nous avons vérifié le pool d'applications plusieurs fois pour nous assurer qu'il n'activait pas les applications 32 bits.

Sur un coup de tête, j'ai essayé de basculer le réglage. Il s'avère que les pools d'applications dans IIS étaient définis par défaut sur une valeur Activer les applications 32 bits de False, mais IIS l'ignorait sur notre serveur pour une raison quelconque et exécutait toujours notre service en mode x86.

Solution

• Sélectionnez le pool d'applications.
• Choisissez Set du pool d' applications par défaut ... ou Paramètres avancés ... .
• Définissez Activer les applications 32 bits sur Vrai.
• Cliquez sur OK .
• Choisissez Set du pool d' applications par défaut ... ou Paramètres avancés ... à nouveau.
• Redéfinissez Activer les applications 32 bits sur False.
• Cliquez sur OK .

J'ai résolu ce problème en modifiant l'application Web pour utiliser un autre «pool d'applications».

Pour tous ceux qui peuvent arriver ici plus tard ... Rien n'a fonctionné pour moi. Toutes mes assemblées allaient bien. J'avais une configuration d'application dans l'un de mes projets Visual Studio qui n'aurait pas dû être là. Assurez-vous donc que votre fichier de configuration d'application est nécessaire.

J'ai supprimé la configuration d'application supplémentaire et cela a fonctionné.

Target build x64 Target Server Hosting IIS 64 Bit

Si la version de l'application cible le système d'exploitation 64 bits, sur le serveur 64 bits hébergeant l'IIS, définissez l'application enable 32 bits sur le pool d'applications exécutant le site Web / l'application Web sur false.

Déterminez le pool d'applications utilisé par l'application et définissez la propriété de en définissant Activer les applications 32 bits sur True. Cela peut être fait via les paramètres avancés du pool d'applications.

Lors de la création d'applications pour une plate-forme 32 bits ou 64 bits (mon expérience est avec Visual Studio 2010), ne comptez pas sur le Gestionnaire de configuration pour définir la plate-forme correcte pour l'exécutable. Même si le CM a sélectionné x86 pour l'application, vérifiez les propriétés du projet (onglet Construire): il peut toujours indiquer "N'importe quel CPU". Et si vous exécutez un exécutable "Any CPU" sur une plate-forme 64 bits, il fonctionnera en mode 64 bits et refusera de charger vos DLL d'accompagnement qui ont été construites pour la plate-forme x86.

Supprimez votre dépendance à System.Runtime dans votre Web.Config, cela a fonctionné pour moi:

<dependentAssembly>
        <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.10.0" newVersion="4.0.10.0" />
</dependentAssembly>

Pour .NET Core , il existe un bogue Visual Studio 2017 qui peut entraîner l'affichage de la page de génération des propriétés du projet la cible de plateforme incorrecte. Une fois que vous découvrez que le problème est, les solutions de contournement sont assez simples. Vous pouvez changer la cible en une autre valeur, puis la modifier à nouveau.

Vous pouvez également ajouter un identificateur d'exécution au .csproj. Si vous avez besoin que votre .exe s'exécute en tant que x86 afin qu'il puisse charger une DLL native x86, ajoutez cet élément dans un PropertyGroup:

<RuntimeIdentifier>win-x86</RuntimeIdentifier>

Un bon endroit pour placer ceci est juste après l' élément TargetFrameworkou TargetFrameworks.

Je suis surpris que personne d'autre n'ait mentionné cela, donc je partage au cas où aucune des solutions ci-dessus n'aiderait (mon cas).

Ce qui se passait, c'est qu'une instance de VBCSCompiler.exe était en quelque sorte bloquée et ne libérait en fait pas les descripteurs de fichier pour permettre aux nouvelles instances d'écrire correctement les nouveaux fichiers et provoquait le problème. Cela est devenu évident lorsque j'ai essayé de supprimer le dossier «bin» et que je me plaignais qu'un autre processus utilisait des fichiers là-dedans.

VS fermé, gestionnaire de tâches ouvert, a regardé et terminé toutes les instances de VBCSCompiler et supprimé le dossier "bin" pour revenir là où j'étais.

Référence: https://developercommunity.visualstudio.com/content/problem/117596/vbcscompilerexe-process-stays-runing-after-exiting.html

Pour tous ceux qui peuvent arriver ici plus tard ...
Pour la solution Desktop, j'ai eu une BadImageFormatExceptionexception.
Toutes les options de construction du projet étaient correctes (toutes x86). Mais le projet StartUp de la solution a été changé en un autre projet (projet de bibliothèque de classes).

Changer le projet StartUp en l'original (projet d'application .exe) était une solution dans mon cas

Lorsque j'ai rencontré ce problème, les éléments suivants l'ont résolu pour moi:

J'appelais une dll OpenCV à partir d'un autre exe, ma dll ne contenait pas les dll opencv déjà nécessaires comme highgui, features2d, etc. disponibles dans le dossier de mon fichier exe. J'ai copié tout cela dans le répertoire de mon projet exe et cela a soudainement fonctionné.

Cette erreur «Impossible de charger le fichier ou l'assembly 'exemple' ou l'une de ses dépendances. Une tentative de chargement d'un programme avec un format incorrect» est généralement due à une configuration incorrecte du pool d'applications.

1. Assurez-vous que l'AppPool sur lequel votre site s'exécute actuellement a «Activer les applications 32 bits» défini sur False.
2. Assurez-vous que vous utilisez la bonne version pour votre plate-forme.
3. Si vous obtenez cette erreur sur un site Web, assurez-vous que votre pool d'applications est configuré pour s'exécuter dans le mode correct (les sites 3.0 doivent s'exécuter en mode 64 bits)
4. Vous devez également vous assurer que la référence à cet assembly dans Visual Studio pointe vers le fichier correct dans le dossier packages.
5. Assurez-vous que la version correcte de la DLL est installée dans le GAC pour les sites 2.0.
6. Cela peut également être dû à la promotion des WSODLib avec le projet Web.