Dev Faq
12
votes

Comment forcer l'application .NET à exécuter en mode 32bit

J'essaie d'exécuter mon application WinForms .NET 3.5 sur une Win7 X64. L'application utilise NHibernate et le système.data.oracleclient pour accéder à une base de données Oracle. Le client Oracle est 32bit.

Lorsque vous commencez l'application, je reçois le message d'erreur suivant

Tentative de chargement des bibliothèques client Oracle a lancé BadimageFormatException. Ce problème se produira lors de l'exécution en mode 64 bits avec les composants 32 bits Oracle Client installés.

En réponse à cela, j'ai ciblé ma construction à la plate-forme x86:

Capture d'écran des paramètres de construction

à ma surprise, Le même message d'erreur est apparu lorsque vous essayez d'exécuter cette nouvelle construction sur la plate-forme Win7. < p> L'ensemble NHibernate est chargé à l'exécution par assemblage.load ("..."); .

pourrait-il être que la DLL de NHibernate fonctionne toujours en mode 64 bit pendant que L'EXE hôte fonctionne en mode 32 bits. Cela vous semble étrange. Ou peut-être que pour une raison quelconque, ma demande fonctionne en mode 64 bits, même s'il était ciblé à X86?

Mise à jour:

J'ai vérifié mon binaire à l'aide de Corflags, et il est marqué 32 bits: xxx

Je l'ai également vérifié dans le gestionnaire de tâches, et il dispose d'un * 32 Suffixe.

J'ai également essayé et utilisé Corflags pour ajouter le drapeau 32 bits à tous les assemblages avec mon application. Il donne toujours le même message d'erreur.

Je suis perplexe ... Pressé ... Pressez ...

5 commentaires

Avez-vous vérifié via le responsable de la tâche que votre programme fonctionne en mode 32 bits ou 64 bits lorsqu'il se bloque? S'il a "* 32" derrière son nom de processus, il est 32 bits, sinon 64 bits (supposant un système d'exploitation et système 64 bits.)

Et qu'avez-vous cible à x86? Votre bibliothèque de classe? Votre programme? Tous les deux?

@Lasse: En détail, l'application est composée de 3 couches, 2 dlls et 1 EXE, tandis qu'une DLL se réfère à NHibernate. J'ai ciblé tous ceux-ci à X86 et nous nous sommes assurés que le projet EXE utilise les bacs X86 des projets DLL lors de la compilation. La seule chose que je ne peux pas contrôler est la DLL NHibernate elle-même.

Êtes-vous sûr que les assemblages NHibernate sont des processeurs et non 64 bits?

@Lasse: Oui, puisque la demande s'exécute en douceur sous Windows XP 32 bit. Je devrais peut-être essayer de télécharger la source et la compiler seul, mais cela rend le processus de construction et de déploiement beaucoup plus compliqué, et je peux à peine croire que l'ensemble chargé dans le processus EXE peut fonctionner dans un mode différent. que l'exe lui-même. Cependant, je ne suis pas un expert dans les profondeurs de .net ...

6 Réponses :

3
votes

Correct, il semble que l'ensemble NHibernate est construit avec anycpu comme objectif de plate-forme. Vous aurez besoin d'un ensemble NHibernate construit pour X86 spécifiquement.

6 commentaires

Salut SixletterSarvariables. Cela signifie-t-il que lorsqu'un EXE fonctionne en mode 32 bits, une DLL chargée dans le même processus peut toujours exécuter en mode 64 bits? Es-tu sûr? Ce serait assez malheureux car je ne contrôlais pas les bâtiments NHibernate ...

Non, comme je l'ai écrit dans ma réponse, un processus 32 bits ne peut pas charger des DLL 64 bits.

@Helge: Je dis que cela a chargé une DLL AnyCPU, qui a ensuite demandé une DLL 64 bits.

@sixlettervariables: L'EXE que j'ai compilé est marqué comme 32 bits. Je pense que le point de Helge est que puisqu'il s'agit de 32 bits, NHibernate doit également fonctionner en mode 32 bits, même s'il était en construction pour anycpu .

@chiccodoro: Je ne peux pas obtenir d'applications de test à une erreur de la même manière, à l'aide de Assembly.load et un mélange de DLL AnyCPU sur un exécutable X86.

@sixlettervariables: très étrange, n'est-ce pas? Merci beaucoup pour vos efforts! Nous verrons comment procéder avec ce problème. Nous essayons également d'obtenir un client Oracle 64bit fonctionnant (en parallèle avec un client 32 bits) et utiliser l'application. Bien sûr, il n'est pas satisfaisant de laisser ce problème ouvert. Peut-être que je reviendrai à un stade ultérieur.

6
votes

Les processus 32 bits ne peuvent pas charger des dlls 64 bits et vice versa (voir Ceci pour plus de détails). Cela signifie que si votre processus a chargé avec succès une DLL de 64 bits, elle est très certainement un processus de 64 bits. Vous pouvez vérifier que dans le gestionnaire de tâches (comme l'a suggéré Lasse) ou via d'autres moyens décrits ici . Cet article dispose également de plus d'informations sur .NET sur Windows X64.

1 commentaires

Salut Helge, merci pour la réponse. C'est ce que j'aurais compté aussi (que DLL doit fonctionner dans le même mode que leur processus hôte). J'ai vérifié dans le chef de la tâche et à l'aide de Corflags, et mon EXE est 32 bits. (Voir la mise à jour de ma question).

0
votes

Si cela aide quiconque, je rencontrais les mêmes symptômes avec Oracle 64 bits et Windows 7 64 bits. J'ai laissé la cible de la plate-forme seule (n'a changé aucun paramètre de projet). Au lieu de cela, j'ai simplement installé Oracle 32 bit et qui résolvait le problème. Assurez-vous de mettre à jour vos variables d'environnement (c'est-à-dire le chemin) pour pointer vers la version 32 bits.

1 commentaires

assez drôle, j'avais les problèmes avec 32 bits et, à la fin, l'installation de 64 bits résolvait!

2
votes

Vous pouvez essayer runasx86

J'utilise cet outil pour démarrer .NET Applications en mode X86, lors de l'exécution de la ligne de commande.

0 commentaires
0
votes

J'ai déjà rencontré un problème similaire. J'ai un service Windows utilisant des rapports de cristal, tout allait bien sur ma machine 64B, j'ai tout accordé - le projet a été construit pour utiliser l'architecture X86.

Le problème est survenu lorsqu'il est déployé sur une machine différente, le service échouait car le moteur de rapports de cristal ne pouvait pas charger log4net.dll 1.2.10 assemblage. J'ai vérifié le répertoire - la version il y avait 1.2.11 , mon annuaire local contenait la même version. Le Bindingredirect n'a pas fonctionné.

Puis j'ai vérifié les dlls GAC - CR sont signés et ont été ajoutés à GAC par installateur, log4net 1.2.10 était là, mais l'architecture du processeur n'était pas x86 . Après avoir ajouté le log4net 1.2.10 pour x86 architecture, il fonctionnait comme un charme.

1 commentaires

Je voulais partager mon histoire et montrer qu'après tout, il s'agissait de l'installation de la version appropriée à GAC.

0
votes

J'ai la même erreur dans ma application C ++ Oracle que je dois exécuter sur une machine de 64 bits dans la machine 32 bits. L'erreur d'image incorrecte est due à l'intermixation des DLL de 32 bits et 64 bits afin que j'ai utilisé la dépendance Walker pour trouver quelles dlls sont mélangées. Dans cette application, j'ai trouvé que OCI.DLL est de 64 bits, car j'ai installé Oracle Client de 64 bits, mais toutes les autres DLL de 32 bits. J'ai donc installé le client Oracle pendant 32 bits sur 64 bits et résolu cette erreur.

0 commentaires

Articles qui pourrait vous intéresser :

Comment x86 bsr / bsf peut-il avoir une latence fixe et non dépendante des données? Ne boucle-t-il pas sur des bits comme le montre le pseudocode?
Moyen rapide d'obtenir un nombre proche de la puissance de 2 (virgule flottante)
C ++ Sysenter X86 appelle à Assemblée en ligne
Comprendre la décompilation d'un objet au code source