Q

"Tentative de chargement d'un programme avec un format incorrect" même lorsque les plates-formes sont identiques

2010-01-07 3 views 382 likes

382

J'appelle des fonctions d'une DLL non gérée 32 bits sur un système 64 bits. Ce que j'obtiens est:"Tentative de chargement d'un programme avec un format incorrect" même lorsque les plates-formes sont identiques

BadImageFormatException: Une tentative a été faite pour charger un programme avec un format incorrect. (Exception de HRESULT: 0x8007000B)

Dans un premier temps, mes projets étaient configurés sur la plate-forme Any CPU, je les ai donc tous deux modifiés en x86, mais cette erreur persiste. C'est vraiment la seule solution que je connais pour ça. Les DLL ne sont pas corrompues ou quoi que ce soit, parce que je peux les utiliser avec d'autres programmes (dont je n'ai pas la source). Je pensais que ce n'était peut-être pas une dépendance, mais j'ai vérifié et ils sont tous là. De plus, ne serait-il pas jeter un DllNotFoundException dans ce cas?

Que puis-je faire d'autre? Et avant de dire "Utiliser une DLL non gérée 64 bits à la place", permettez-moi de souligner qu'il n'y en a pas.

2010-01-07 David Brown

+1

Quels projets avez-vous changé en x86? Et comment les exécutez-vous lorsque vous obtenez l'exception, via le débogueur ou manuellement? Si ce dernier, avez-vous remarqué que lorsque vous avez changé en x86, vous avez un nouveau dossier dans votre répertoire bin \? Il s'agit essentiellement de bin \ x86 \ Debug pour les fichiers. –

+0

Pouvez-vous vérifier que l'exécutable s'exécute en mode 32 bits (* 32 dans le gestionnaire de processus)? –

+0

@Lasse V. Karlsen: Oui, j'ai enlevé le bit x86 du chemin de sortie quand j'ai changé la plate-forme dans chaque projet. Mon premier projet est une DLL qui encapsule les fonctions dans la DLL non managée. Le deuxième projet est un exécutable qui utilise le wrapper dans la première DLL. Les deux sont définis sur x86. –

A

Répondre

112

La case à cocher Build dans le Gestionnaire de configuration a été décochée pour mon fichier exécutable, donc il fonctionnait toujours avec l'ancienne génération Any CPU. Après avoir résolu cela, Visual Studio s'est plaint qu'il ne pouvait pas déboguer l'assembly, mais cela a été résolu avec un redémarrage.

2010-01-08 01:59:53

+0

Merci beaucoup. Cela m'a aussi Vérification de la construction dans Configuration Manager et maintenant cela fonctionne (application de bureau WPF). – danglund

+1

Si vous avez fait tout ce qui précède, et vérifié les paramètres de votre plate-forme, construire les paramètres de configuration, nettoyé la solution et il ne fonctionne toujours pas - rechercher toutes les instances de la DLL et les supprimer. –

+4

J'ai changé l'option Any CPU à X86 et cela a fonctionné pour moi ..! – mithilatw

471

Si vous essayez d'exécuter des applications 32 bits sur IIS 7 (et/ou un système d'exploitation 64 bits), vous obtiendrez la même erreur. Ainsi, depuis IIS 7, faites un clic droit sur le pool d'applications des applications et allez dans "Paramètres avancés" et remplacez "Activer les applications 32 bits" par "VRAI".

Redémarrez votre site web et cela devrait fonctionner.

enter image description here

2011-01-06 20:08:11 bluwater2001

+0

Oh mes jours, j'ai pêché autour de l'installation de composants IIS supplémentaires quand c'était la réponse ... Quelqu'un peut-il suggérer un inconvénient à avoir cette option sélectionnée? – notidaho

+2

Voici une bonne discussion sur la question de la performance à ce sujet: http://stackoverflow.com/questions/507820/what-are-the-pros-and-cons-of-running-iis-as-32bit-vs- 64bit-on-a-64bit-os –

+0

J'ai un problème avec SharpSvn et cela n'aide pas.:( Sth est très mauvais avec cet assemblage je vous dis ... – user2173353

43

Je viens d'avoir ce problème aussi. J'ai essayé toutes les suggestions ici, mais ils n'ont pas aidé.

J'ai trouvé une autre chose à vérifier qui l'a corrigé pour moi. Dans Visual Studio, cliquez avec le bouton droit sur le projet et ouvrez "Propriétés". Cliquez sur l'onglet "Compiler" puis cliquez sur "Options de compilation avancées" en bas.

Vérifiez la liste déroulante "CPU cible". Cela devrait correspondre à la "Plateforme" que vous construisez. Autrement dit, si vous construisez "Any CPU" alors "Target CPU" devrait dire "Any CPU". Parcourez toutes vos plates-formes en les activant et vérifiez ce paramètre.

2011-12-12 19:13:01 Denis

+2

Et pour ceux d'entre nous en utilisant simplement le compilateur, ma solution était pour ajouter "/ platform: x86" aux drapeaux du compilateur – Urchin

+0

Cela m'a aussi permis de corriger la "cible de la plateforme" dans l'onglet "Build" – Jowen

2

Dans mon cas, j'utilise un petit .exe qui recharge les DLL référencées via Reflection. Donc, je fais juste ces étapes qui me sauve jour:

des propriétés du projet sur l'explorateur de solution, à l'onglet de construction, je choisis la cible platfrom x86

2012-02-15 09:21:50

3

Voir aussi this answer, qui a résolu pour moi le même problème.

Publié par Luis Mack le 05/12/2010 à 08h50 J'ai rencontré le même problème, uniquement pour un projet spécifique lors de la compilation sur une machine 64 bits.Un correctif qui semble fonctionner est de modifier manuellement un caractère flux dans l'image chaque fois que le usercontrol ou la forme est édité dans le concepteur
AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00LjAuMC4w 
Modification
AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0yLjAuMC4w 
C'est 00LjAuMC4w retour à 0yLjAuMC4w à la fin de la ligne (00 retour à 0y)

2012-03-21 13:45:20

+1

Un bref résumé du lien serait utile @Shaul :) –

+1

@MarvinThobejane - fait –

+0

Magnifique. Merci, le briefing ajoute du contenu à votre commentaire –

8

Un peu hors sujet pour ce poste, mais searchin g pour ce message d'erreur m'a amené ici.

Si vous développez via le système d'équipe et obtenez cette erreur, l'onglet de processus de définition de génération dispose d'un paramètre «MSBuild Platform». Si cela est défini sur "Auto", vous pouvez rencontrer ce problème. Le changer en "X86" peut également résoudre l'erreur.

2012-10-05 13:55:56 StingyJack

+0

c'est la réponse la plus proche de ce que je vivais. J'ai eu une DLL qui devait être x86. Je l'ai utilisé dans un autre projet, qui était AnyCPU par défaut. Ils ont juste besoin de correspondre. Dans ce cas, cela n'a pas fait beaucoup de différence, donc j'ai changé le nouveau projet en x86. – greg

7

Dans mon cas, j'utilisais une DLL native en C#. Cette DLL dépendait de quelques autres DLL manquantes. Une fois ces autres DLL ajoutées, tout a fonctionné.

2012-12-11 20:30:25

1

J'ai résolu ce problème de la manière 'Windows'. Après avoir vérifié tous mes paramètres, nettoyé la solution et l'avoir reconstruite, je ferme simplement la solution et la rouvre. Ensuite, cela a fonctionné, alors VS ne s'est probablement pas débarrassé de certaines choses pendant le nettoyage. Lorsque les solutions logiques ne fonctionnent pas, je me tourne généralement vers des solutions illogiques (ou apparemment illogiques). Windows ne me laisse pas tomber. :)

2013-04-30 09:38:40 user1771386

21

Si vous utilisez Tout CPU, vous pouvez rencontrer ce problème si la Préférez 32 bits l'option est cochée:

Assurez-vous décocher cette option dans l'onglet de la propriété du projet du projet!

2013-09-24 13:55:06

+3

Il serait utile que vous indiquiez où dans Visual Studio pour trouver cette option. – trysis

+0

@trysis, cette option se trouve dans la page _Build_ du volet des paramètres du projet. –

+1

Je disais qu'il serait utile de le mettre. Comme cette réponse est, il n'y a pas de contexte pour dire à l'infortuné, peut-être un nouvel utilisateur de StackOverflow où le trouver. – trysis

53

Dans Visual Studio, droit Cliquez sur votre projet -> Dans le volet gauche cliquez sur le Construire onglet,

Project properties, build tab

sous plate-forme cible sélectionnez x86 (ou plus généralement le architecture à correspondre à la bibliothèque que vous liez)

Project properties, platform target

J'espère que cela aide quelqu'un! :)

2013-10-21 07:35:49

+2

Cela a résolu mon problème dans VS2013, j'ai trouvé une solution de rechange est de laisser "Target Platform" comme "Any CPU", mais cochez la case "Préférer 32 bits". – user1069816

+2

Bien que vous deviez utiliser .NET 4.5 ou supérieur pour pouvoir cocher la case à cocher "Préférer 32 bits" – user1069816

2

Dans mon cas, j'exécutais des tests via MSTest et j'ai découvert que je déployais à la fois une DLL 32 bits et 64 bits dans le répertoire de test. Le programme favorisait la DLL 64 bits et l'a fait échouer.

TL; DR Assurez-vous de déployer uniquement des DLL 32 bits pour les tests.

2015-05-07 19:30:07

1

J'ai été en mesure de résoudre ce problème en faisant correspondre ma version de build à la version .NET sur le serveur.

Je double cliqué sur le .exe juste pour voir ce qui se passerait et il m'a dit d'installer 4.5 ....

Je rétrogradé à 4.0 et cela a fonctionné! Par conséquent, assurez-vous que vos versions correspondent à celles de votre version. Il a bien fonctionné sur ma boîte de dev, mais le serveur avait une ancienne version .NET.

2015-12-16 21:58:48 Nate

0

Dans mon cas, c'était un mauvais contenu du fichier. DLL a été téléchargé à partir du Web, mais le contenu de la DLL était la page HTML: D Essayez de vérifier si c'est un fichier binaire, si elle semble être la bonne DLL :)

2016-06-22 07:42:11 Ludwo

18

Si vous rencontrez cette erreur lorsque vous cliquez sur le bouton flèche verte pour exécuter l'application, mais toujours envie de lancer l'application en 64 bits. Vous pouvez le faire dans VS 2013 ou 2015

Aller à: Outils> Options> Projets et Solutions> Projets Web> Utilisez la version 64 bits d'IIS express

2016-07-05 13:46:57 paibamboo

0

Miser sur la réponse de @paibamboo

Il a dit: Allez dans: Outils> Options> Projets et solutions> Projets Web> Utiliser la version 64 bits d'IIS Express

Mon collègue a fait cocher cette case (il l'a explicitement recherchée), mais le message d'erreur en question . Après quelques heures, il décoche la boîte et la vérifie à nouveau. Lo and behold: Le code a maintenant couru avec succès.

Il semble qu'il y ait deux endroits où l'état de cette boîte est sauvegardé qui est devenu désynchronisé. Un- et une nouvelle vérification l'ont encore synchronisé. Question pour les utilisateurs plus avertis: Y a-t-il eu une mise à jour ou quelque chose la semaine dernière (pour VS 2015) qui a désynchronisé les états?

2017-10-16 14:42:53 MilConDoin

Questions connexes