Impossible de charger le fichier ou l'assembly… Une tentative a été effectuée pour charger un programme avec un format incorrect (System.BadImageFormatException)


409

J'ai deux projets, ProjectAet ProjectB. ProjectBest une application console, qui dépend de ProjectA. Hier, tout fonctionnait bien, mais tout à coup aujourd'hui, quand je cours, ProjectBje reçois ceci:

BadImageFormatException n'a pas été gérée :
impossible de charger le fichier ou l'assembly «ProjectA, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null» ou l'une de ses dépendances. Une tentative a été effectuée pour charger un programme avec un format incorrect.

Les deux sont juste des projets réguliers, sans dépendances sur d'autres projets non-Net. Les deux sont entièrement .Net - il n'y a pas de code natif et pas de P / Invoke. J'ai d'autres projets qui dépendent ProjectAet fonctionnent toujours très bien.

Ce que j'ai essayé:

  • Assurez-vous que les deux projets sont définis sur «Any CPU», avec la case à cocher de construction cochée. Elles sont.
  • Assurez-vous que les deux projets concernent le même framework cible (profil client .Net 4.0) .
  • Sous ProjectB -> Références -> ProjectA -> Propriétés, assurez-vous que "Copier local" est défini sur "Vrai" _ (J'ai vérifié que ProjectA.dll est copié correctement)
  • Nettoyez / reconstruisez la solution. J'ai même essayé de supprimer manuellement les dossiers / bin et / obj dans les deux projets.
  • Redémarrez Visual Studio. Redémarrez mon ordinateur.
  • Découvrez une toute nouvelle copie du référentiel.

Mais je reçois toujours la même erreur. Je n'ai aucune idée de ce que j'ai fait pour provoquer cela, ni comment y remédier. Des idées?


1
Si vous avez un historique des versions dans le référentiel, pourriez-vous vérifier s'il y a des différences dans les fichiers csproj?
Steve

@Steve: Selon Mercurial, aucun changement autre que l'ajout de références à de nouveaux fichiers .cs
BlueRaja - Danny Pflughoeft

Obtenez-vous le même comportement sur une autre machine? Quelque chose d'autre a-t-il changé sur la machine (par exemple, mise à jour Windows, mises à jour des dépendances, etc.)?
Mike Parkhill

Avez-vous essayé de restaurer ces nouveaux fichiers .cs?
Mike Parkhill

2
Cela a fonctionné pour moi ............ stackoverflow.com/a/9419522/191403
Som

Réponses:


647

Je suis sûr que vous rencontrez un conflit 32 bits / 64 bits. Il semble que votre projet principal soit défini sur 32 bits tandis que la classe dont il est référencé est définie sur 64 bits. Essayez de regarder cette question SO et celle-ci aussi . Entre les deux, vous devriez être en mesure de comprendre votre problème.


71
Do'h. En quelque sorte, la liste déroulante "cible de la plate-forme" est complètement manquante project-->properties-->build- elle a été définie pour x86; le paramétrer sur "N'importe quel CPU" a résolu ce problème. J'ai toujours pensé que ce paramètre était le même que la liste déroulante "cible de plate-forme" dans le gestionnaire de configuration, mais apparemment ce n'est pas le cas (en fait, la "cible de plate-forme" dans le gestionnaire de configuration ne semble rien faire du tout!)
BlueRaja - Danny Pflughoeft

10
Vérifiez également que le projet n'est pas Any CPU avec Prefer 32 bits coché. Projet -> propriétés -> construire
Reid Evans

26
PS: Une autre raison est que «Activer les applications 32 bits» est «faux» dans les paramètres du pool d'applications. Vous devez redémarrer IIS après l'avoir défini sur true.
dvdmn

3
Le pire qui m'est arrivé avec cette erreur a été lorsque VS a décidé d'ajouter <PlatformTarget>x86</PlatformTarget>un des projets dépendants sans aucune raison. Si je n'ai pas examiné SVN, je n'aurais jamais compris pourquoi notre application MVC ne se lance pas.
jahu

1
Veuillez définir dans IIS DefaultAppPool-> Activer les applications 32 bits = True
Shantu

198

Il se peut que vous rencontriez le problème avec votre site Web après le déploiement sur le serveur.

Ensuite, vous devez ajuster votre pool d'applications pour activer les applications 32 bits .

Pas

  1. Ouvrez IIS Manager
  2. Cliquez sur Pools d'applications
  3. Sélectionnez le pool d'applications que vous utilisez
  4. Dans le volet droit, cliquez sur Paramètres avancés ...

  5. Définissez Activer les applications 32 bits sur True

    Réglages avancés Activer 32 bits


1
Ai-je oublié quelque chose? OP parle d'une application console et non d'un déploiement IIS: "ProjectB est une application console, qui dépend de ProjectA"
MickyD

129

Je viens de recevoir ce message d'erreur lors de l'exécution d'IIS Express dans Visual Studio 2015. Dans mon cas, j'avais besoin d'exécuter la version 64 bits d'IIS Express:

Outils → Options → Projets et solutions → Projets Web
Cochez la case "Utiliser la version 64 bits d'IIS Express pour les sites Web et les projets".

Capture d'écran:

Capture d'écran des options VS pour Web Project.


2
L'inverse s'applique à, j'ai fait
cocher la case

32

J'ai eu le même problème. J'avais défini la «cible de plate-forme» du projet A («projet A» (clic droit) -> Propriétés -> Build -> «cible de plate-forme») sur x86, mais je gardais le projet B sur «Any CPU». La définition du projet B sur "x86" a corrigé ce problème.


15

J'ai rencontré ce problème lors de l'exécution de tests unitaires (xunit) dans Visual Studio 2015 et j'ai rencontré le correctif suivant:

Menu Bar -> Test -> Test Settings -> Default Processor Architecture -> X64

7

Vous devrez peut-être modifier le paramètre Pool d' applications "Activer les applications 32 bits" sur VRAI dans IIS7 si vous avez au moins 1 DLL 32 bits \ exe dans votre projet.


OP parle d'une application console pas IIS
MickyD

5

Tout d'abord, j'ai obtenu cela dans VS2017 avec un ancien projet dont j'avais besoin pour faire un petit changement et mettre à niveau tous les projets vers le framework 4.7.


Plusieurs autres ont mentionné que la sélection Any CPUpeut résoudre ce problème.

Il y a quelques endroits où vous devez le faire, et ce n'est peut-être pas aussi simple que de sélectionner dans la liste déroulante. Cela m'a corrigé:

1) Vous devez faire les deux ici:

entrez la description de l'image ici

2) Et aussi en Configuration Manager(clic droit sur la solution)

entrez la description de l'image ici

Mais si ce n'est pas là ???

Cliquez ensuite Newet choisissez ces paramètres: ( merci @RckLN )

entrez la description de l'image ici


2

J'ai eu le même problème avec plusieurs projets dans la même solution, j'ai fini par définir tous les cadres cibles sur .NET Framework 4 et x86 pour le processeur cible et il a finalement été compilé avec succès.


1
A fonctionné dans la version mais a échoué dans le débogage. Définissez tout sur .Net Framework 4 (PAS la mise à jour 1) et le débogage s'exécute maintenant.
DCastenholz

2

Vous pouvez également voir ce problème si vous essayez de regrouper un projet 64 bits avec un programme d'installation MSI dans VS. ("La raison en est que le module d'interface natif fourni avec le fichier .msi est un exécutable 32 bits.")

Voir ici pour plus de détails: http://blogs.msdn.com/b/heaths/archive/2006/02/01/64-bit-managed-custom-actions-with-visual-studio.aspx


1
Envisagez de résumer l'article lié au profit des futurs lecteurs; au cas où le lien disparaîtrait.
Bond - Java Bond

2

Aucune de ces solutions n'a fonctionné pour moi - mais en supprimant le contenu des dossiers bin et obj, tout était à nouveau cool.


2

Je l'ai obtenu lors de la création d'un projet via Visual Studio Online (VSTS) Build à l'aide d' Visual Studio Buildétapes.

La solution était:

  • Supprimer le dossier source existant
  • Définissez explicitement 'Any CPU' dans la plate-forme pour toutes les versions de Visual Studio, y compris les dépendances (voir capture d'écran ci-dessous).
  • Réexécutez la génération

Capture d'écran VSO


2

Ce qui suit a résolu le problème pour moi, décochez 'Préférer 32 bits': entrez la description de l'image ici


1

J'ai rencontré le même problème. Il est apparu à l'improviste et cela m'a paru étrange.

Dans l'instantané d'exception, pour le FusionLog, j'ai vu ce qui suit dans son message:

... C: \ Windows \ Microsoft.NET \ Framework64 ...

En savoir plus sur le journal de fusion: http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.110).aspx

Tous les projets avaient un CPU cible d'AnyCPU. J'ai changé le projet d'application (le projet qui fait référence à tous les autres projets) en CPU cible de x86. Ça marche maintenant.

Je ne sais pas comment le mélange de CPU cible s'est produit sans raison apparente, mais il l'a fait.


1

Je suis également confronté à ce problème dans un projet, après quelques minutes, j'ai trouvé la solution, ce problème est dû à la configuration du processeur.Si vous utilisez Visual Studio 2010 ou VS 2013 , accédez simplement aux propriétés du projet, puis sélectionnez Compiler dans la barre latérale. et il y aura 5 listes déroulantes, la 5ème liste déroulante sera CPU cible:, vous devez le définir sur x86 ou x64 selon vos besoins au lieu de N'importe quel CPU.

Mon problème a été résolu après l'avoir changé en x86.


1

Cela peut également se produire simplement en ayant plusieurs cadres pris en charge définis dans le fichier app.config et en forçant l'application à s'exécuter dans un autre cadre .NET autre que celui mentionné en premier dans le fichier app.config .

Et cela se déclenche également lorsque vous disposez des deux cadres mentionnés dans votre système.

Pour contourner le problème, affichez le framework cible que vous allez utiliser pour le débogage dans app.config

ex: si vous essayez d'exécuter dans .NET 4, le fichier de configuration devrait avoir quelque chose de similaire à cela,

<supportedRuntime version="v4.0"/>
<supportedRuntime version="v2.0.50727"/>

1

Dans mon projet pour C #, propriété du projet -> [Build] -> Target platform: Any CPU, et décochez la préférence 32 bits pour laisser le compilateur choisir automatiquement.


1

L'assembly Chilkat .NET 4.5 nécessite que le runtime VC ++ 2012 ou 2013 soit installé sur n'importe quel ordinateur sur lequel votre application s'exécute. La plupart des ordinateurs l'ont déjà installé. Votre ordinateur de développement l'aura car Visual Studio a été installé. Cependant, si le déploiement sur un ordinateur où le runtime VC ++ requis n'est pas disponible, l'erreur ci-dessus se produira:

Installez tous les packages ci-dessous

Packages redistribuables Visual C ++ pour Visual Studio 2013 - vcredist_x64

Packages redistribuables Visual C ++ pour Visual Studio 2013 - vcredist_x86

Packages redistribuables Visual C ++ pour Visual Studio 2012 - vcredist_x64

Packages redistribuables Visual C ++ pour Visual Studio 2012 - vcredist_x86



0

Cela peut être un peu drôle, mais j'ai eu le même problème avec le code de travail normal. J'ai ajouté StreamWriter et StreamReader et cela a donné cette erreur. La solution était que j'ai pris ce code entre crochets de commentaires, puis j'ai débogué et cela a recommencé à fonctionner



0

Dans mon cas, une dépendance manquait dans la DLL qui a déclenché cette exception. J'ai vérifié avec Dependency Walker, ajouté la DLL manquante et le problème a été résolu.

Plus spécifiquement, j'ai en quelque sorte corrompu mon opencv_core340.dll en y ajoutant accidentellement des mots clés SVN, et donc ma DLL ne pouvait plus l'utiliser. Cependant, je ne pense pas que la solution à ce problème dépende de savoir si la DLL est corrompue ou manquante. J'ajoute juste ceci pour donner des informations complètes.


0

Tirer! Je connaissais ce problème. Je pensais que je faisais tout correctement jusqu'à ce que je voie accidentellement 'x86' dans la fenêtre de sortie VS et c'est à ce moment que j'ai saisi la cause. J'ai perdu quelques minutes dessus aujourd'hui.

La configuration sous la fenêtre «Publier» a été définie sur «x86»; alors que partout ailleurs, c'était «x64».

Veuillez vous assurer qu'il est synchronisé dans le gestionnaire de configuration, publier les paramètres, les configurations de solution et les paramètres IIS (s'il s'agit de votre serveur Web).

Gardez également à l'esprit que VS est une application 32 bits et IIS 64 bits. Les applications 32 bits sont désactivées par défaut dans IIS.

entrez la description de l'image ici


0

J'ai détecté quelque chose de différent des autres réponses. Atteindre cette exception dans mon projet est le résultat d'une compilation corrompue. Sans apporter de modifications, juste forcer la reconstruction , il a été corrigé.


0

J'ai eu le même problème. Le projet B dans mon cas était une bibliothèque de classes .Net Core sur laquelle un Nuget "Microsoft.Management.Infrastructure" est installé. L'erreur était que j'ai appelé mon projet B "MI". J'ai changé le nom du projet pour quelque chose d'autre et soudain, tout a recommencé.


-1

Ma machine m'a montré une mise à jour du BIOS et je me suis demandé si cela avait quelque chose à voir avec l'apparition soudaine de cette erreur. Et après avoir effectué la mise à jour, l'erreur a été résolue et la solution s'est bien intégrée.


-1

Essayez-vous d'exécuter votre fichier .exe à partir de la cmd? C'était mon erreur. Exécutez simplement le fichier .exe en double-cliquant dessus. S'il s'agit d'un .NET Core SCD pour Windows 8.1 / Windows Server 2012 R2 x64.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.