Impossible de charger le fichier ou l'assembly ... Une tentative de chargement d'un programme avec un format incorrect a été effectuée (System.BadImageFormatException)
J'ai deux projets, ProjectA et ProjectB. ProjectB est une application console, qui dépend de ProjectA. Hier, tout fonctionnait bien, mais soudainement, lorsque je cours, ProjectB, je reçois ceci:
BadImageFormatException non gérée :
Impossible de charger le fichier ou l'assembly 'ProjectA, version = 1.0.0.0, Culture = neutre, PublicKeyToken = null' ou l'une de ses dépendances. Une tentative de chargement d'un programme avec un format incorrect a été effectuée.
Les deux ne sont que des projets réguliers, sans dépendance vis-à-vis des 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 de ProjectA et fonctionnent toujours très bien.
Choses que j'ai essayées:
- Assurez-vous que les deux projets sont définis sur "Tout processeur", en cochant la case build. Elles sont.
- Assurez-vous que les deux projets correspondent au même cadre cible (profil client .Net 4.0).
- Sous ProjectB -> Références -> ProjectA -> Propriétés, assurez-vous que "Copier Local" est défini sur "True" _ (j'ai vérifié que ProjectA.dll était copié correctement).
- Nettoyer/reconstruire 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 copie entièrement nouvelle 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 causer cela, ni comment y remédier. Des idées?
Je suis à peu près 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 à laquelle il fait référence est définie sur 64 bits. Essayez de regarder cette SO question et celle-ci aussi . Entre les deux, vous devriez pouvoir comprendre votre problème.
Peut-être êtes-vous confronté au problème de 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:
- Ouvrir le gestionnaire IIS
- Cliquez sur Pools d'applications
- Sélectionnez le pool d'applications que vous utilisez
- Dans le volet de droite, cliquez sur Paramètres avancés ...
- Définissez Activer les applications 32 bits sur True
Ce message d'erreur lié à l'exécution de IIS Express dans Visual Studio 2015. Il fallait que j'exécute la version 64 bits de IIS Express:
Outils -> Options -> Projets et solutions -> Projets Web
Cochez la case "Utiliser la version 64 bits de IIS Express pour les sites Web et les projets ".
Capture d'écran:
J'ai eu le même problème. J'avais défini la "Plate-forme" du projet A ("Projet A" (clic droit) -> Propriétés -> Construire -> "Cible de la plate-forme") sur x86 tout en maintenant le projet B sur "Tout processeur". La définition du projet B sur "x86" a résolu ce problème.
J'ai eu ce problème lors de l'exécution des tests unitaires (xunit) dans Visual Studio 2015 et je suis tombé sur le correctif suivant:
Menu Bar -> Test -> Test Settings -> Default Processor Architecture -> X64
Vous devrez peut-être modifier le Pool d'applications et définir "Activer les applications 32 bits" sur TRUE dans IIS 7 si vous avez au moins 1 dll\exe 32 bits dans votre projet.
Tout d'abord, j'ai eu cela dans VS2017 avec un ancien projet dont j'avais besoin pour apporter un tiny changement à tous les projets et les mettre à niveau vers le framework 4.7.
Plusieurs autres ont mentionné que la sélection de Any CPU peut résoudre ce problème.
Vous devez le faire à quelques endroits différents, et ce n'est peut-être pas aussi simple que de le sélectionner dans la liste déroulante. Cela a résolu le problème pour moi:
1) Vous devez faire les deux ici:
2) Et aussi dans Configuration Manager (clic droit sur la solution)
Mais si ce n'est pas là ???
Cliquez ensuite sur New et choisissez les paramètres suivants: ( grâce @RckLN )
Vous pouvez également rencontrer ce problème si vous essayez de conditionner un projet 64 bits avec un programme d’installation MSI dans VS. ("La raison en est que la cale native fournie 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
J'ai eu le même problème avec plusieurs projets dans la même solution, j'ai fini par configurer tous les frameworks cibles sur .NET Framework 4 et x86 pour le CPU cible et le compiler a finalement abouti.
Je l’ai eu lors de la construction d’un projet avec Visual Studio Online (VSTS) Construire à l’aide de Visual Studio Build Steps.
La solution était:
- Supprimer le dossier source existant
- Définissez explicitement 'Tout processeur' sur la plate-forme pour toutes les versions de Visual Studio, y compris les dépendances (voir capture d'écran ci-dessous).
- Re-exécuter la construction
Aucune de ces solutions ne fonctionnait pour moi - mais en supprimant le contenu des dossiers bin et obj, tout était à nouveau cool.
Je rencontre également ce problème dans un projet. Après quelques minutes, j’ai trouvé la solution, Ce problème est dû à la configuration de la CPU, Si vous utilisez Visual Studio 2010 ou VS 2013 , venez au projet 's properties puis sélectionnez Compilez dans la barre latérale et il y aura 5 menus déroulants, le cinquième menu déroulant sera CPU cible: , vous devez le définir sur x86 ou x64 selon vos besoins au lieu de N'importe quel processeur.
Mon problème a été résolu après le changer en x86.
Dans mon projet pour C #, propriété du projet -> [Construire] -> Cible de la plate-forme: Tous les processeurs, .__ et décochez la case Préférer 32 bits pour laisser le compilateur choisir automatiquement.
Si vous utilisez LibreOffice à partir de votre programme via une intégration cli .net comme moi, j'ai la même erreur. J'utilise l'ancienne version de LibreOffice sur l'environnement de production de mon ordinateur. J'ai installé une version plus récente en conflit. Il suffit de désinstaller LibreOffice. J'ai trouvé la solution ici .NET CLI: Impossible de charger le fichier ou l'assembly 'cli_cppuhelper'
J'ai rencontré le même problème. Il est sorti de nulle part et cela m'a semblé étrange.
Dans l'instantané Exception, pour le FusionLog, j'ai constaté ce qui suit dans son message:
... C:\Windows\Microsoft.NET\Framework64 ...
Plus d'informations sur le journal de fusion: http://msdn.Microsoft.com/en-us/library/e74a18c4(v=vs.110).aspx
Tous les projets avaient un CPU cible de AnyCPU. J'ai changé le projet d'application (le projet qui référence tous les autres projets) en un CPU cible de x86. Cela fonctionne maintenant.
Vous ne savez pas comment la confusion de l'unité centrale cible s'est produite sans raison apparente, mais c'est ce qui s'est passé.
Cela peut également se produire simplement en ayant plusieurs frameworks pris en charge définis dans le fichier app.config et en forçant l'application à s'exécuter dans un framework .NET différent de celui mentionné en premier dans l'application. fichier de configuration .
Et cela se déclenche également lorsque les deux cadres mentionnés sont disponibles dans votre système.
En guise de solution de contournement, affichez le cadre cible que vous allez utiliser pour le débogage dans le fichier app.config.
ex: si vous essayez de fonctionner en .NET 4, le fichier de configuration devrait avoir quelque chose de similaire à ceci,
<supportedRuntime version="v4.0"/>
<supportedRuntime version="v2.0.50727"/>
L'assemblage Chilkat .NET 4.5 nécessite l'installation de VC++ 2012 ou 2013 sur tout ordinateur sur lequel votre application est exécutée. La plupart des ordinateurs l'auront déjà installé. Votre ordinateur de développement l’aura parce que Visual Studio a été installé. Toutefois, si vous effectuez un déploiement sur un ordinateur où l'exécution d'exécution VC++ requise n'est pas disponible, l'erreur ci-dessus se produira
Installer tous les paquets 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
J'ai également eu ce problème lors de l'exécution des tests unitaires à l'aide de ReSharper sous Visual Studio 2017 et je l'ai corrigé avec la configuration suivante:
Vous pouvez également modifier les paramètres du test d’exécution de ReSharper: https://resharper-support.jetbrains.com/hc/en-us/articles/207242715-How-to-run-MSTest-tests-using-x64 -configuration
Tirer! Je connaissais ce problème. Je pensais que tout était en ordre jusqu'à ce que je voie par inadvertance «x86» dans la fenêtre de sortie du VS et c'est à ce moment-là que j'ai pu mettre la main sur la cause. J'ai perdu quelques minutes aujourd'hui.
La configuration sous la fenêtre 'Publier' a été définie sur 'x86'; alors que partout ailleurs, c'était 'x64'.
Assurez-vous qu'il est synchronisé sur le gestionnaire de configuration, les paramètres de publication, les configurations de solution et les paramètres IIS (s'il s'agit de votre serveur Web).
De plus, n'oubliez pas que VS est une application 32 bits et que IIS est une version 64 bits. Les applications 32 bits sont désactivées par défaut dans IIS.
Cela peut paraître un peu drôle, mais le même problème se posait avec le code de travail normal. J'ai ajouté StreamWriter et StreamReader et cela a donné l'erreur . La solution a été de prendre ce code dans les crochets de commentaire, puis de déboguer et de recommencer à fonctionner
Dans mon cas, une dépendance manquait dans la dll qui lançait cette exception. J'ai vérifié avec Dependency Walker, ajouté la DLL manquante et le problème a été résolu.
Plus précisément, j’ai corrompu mon opencv_core340.dll en y ajoutant accidentellement des mots-clés SVN, ce qui a empêché ma dll de l’utiliser. Cependant, je ne crois pas que la solution à ce problème dépend de si la dll est corrompue ou manquante. J'ajoute ceci simplement pour donner une information complète.