Question

Mon application .NET 2.0 importe des dll 32 bits non gérées. La dll est chargée (le premier appel interopéré a lieu) lorsque l'utilisateur ouvre un fichier via une boîte de dialogue au sein de l'application.

Lorsque je déploie l'application via clickonce avec la plate-forme cible & "N'importe quel &", les utilisateurs sous Windows 64 bits obtiennent BadImageFormatException lorsqu'ils tentent d'ouvrir des fichiers à partir de l'application (au moment où la dll non gérée est chargée) . Je comprends que cela est dû à la complexité incomparable du processus 64 bits et de la DLL non gérée 32 bits.

J'ai redéployé l'application en utilisant x86 comme plate-forme cible. Si j'ai bien compris, cela devrait résoudre le problème de bitness.

MAIS

Lorsque j'exécute l'application déployée créée pour x86 sur un système 64 bits, j'obtiens maintenant BadImageFormatException immédiatement avant le démarrage de l'application. Testé sur au moins trois machines 64 bits. Sur les machines 32 bits, cela fonctionne sans problème.

Lorsque j'exécute l'application directement à partir de VS (ou pas directement, mais uniquement d'une construction normale, sans passer par ClickOnce), il n'y a pas de problème sous Windows 64 bits avec une plate-forme cible x86. L’application démarre et l’utilisateur peut charger le fichier - l’appel interop a abouti.

Cela fait 2 jours que je débogue pour le déboguer sans résultat - j'ai essayé sur différents ordinateurs. Il semble fonctionner régulièrement sur l’un des ordinateurs que j’ai essayé. Cependant, je n'ai pas d'accès permanent à cet ordinateur.

J'ai réussi à construire le déploiement ClickOnce sur mon ordinateur une fois et cela fonctionnait sur un ordinateur 64 bits. C'était unique de peut-être 100 essais! Rien n'a changé, la seule variable qui a été modifiée est que j'ai construit correctement après le redémarrage de l'ordinateur.

J'ai nettoyé / reconstruit / redémarrez VS / redémarrez Windows BEAUCOUP de fois. J'ai réinstallé VS 2008 et maintenant également le système d'exploitation dans son ensemble, cela n'a pas aidé.

EDIT: Je viens juste d’obtenir une bonne construction (sur 100 prochains :)) et de comparer les répertoires déployés. La source du problème est que ClickOnce génère la mauvaise plate-forme cible dans le manifeste du fichier .exe principal:

<asmv1:assemblyIdentity name="app.exe" version="1.0.4.18" publicKeyToken=".token here." language="neutral" processorArchitecture="<b>msil</b>" type="win32" />

processorArchitecture doit être x86.

La question est donc de savoir comment forcer de manière cohérente VS à générer la bonne architecture de processeur dans le manifeste lors du déploiement.

Quelqu'un peut-il aider s'il vous plaît?

Était-ce utile?

La solution

Ce problème a été résolu en installant VS 2008 SP1 sous Windows 7. 64 bits. VS2008 SP1 sur XP rencontrait le problème sur deux ordinateurs que j'avais essayés.

Autres conseils

J'ai également eu ce problème avec VS2008 SP1. Dans mon cas, j'avais une DLL 32 bits qui devait être compilée en tant que 32 bits et une application qui l'utilisait dans la même solution. Même si j'ai spécifié X86 comme cible de génération pour la version finale, lorsque j'ai publié une application 64 bits, elle a été compilée et incluse dans le programme d'installation. J'ai trouvé une solution légèrement brutale au problème: Accédez au gestionnaire de configuration et supprimez toutes les configurations possibles, à l'exception de celle que vous souhaitez créer (versions de débogage et d'édition). Après cela, j’ai constaté que le programme d’installation clickonce avait été généré avec la bonne application.

J'espère que cela aide quelqu'un d'autre, je lutte de temps en temps contre ce problème.

Je suggérerais d'utiliser Reflector pour ouvrir le fichier exe principal déployé par ClickOnce et voir le dépendances pour vous assurer que vous ne déployez pas la version 64 bits de la DLL par erreur.

Vous devez décider d'exécuter des applications 32 bits dans IIS 7. Voir http://www.fishofprey.com/2009/04/badimageformatexception-in-iis-70-on-64.html

Parfois, le processus de publication ClickOnce semble mettre en cache les anciens fichiers des versions précédentes Any CPU ou x64. Faire un nettoyage et reconstruire tous n'a pas résolu ce problème pour moi. Je devais supprimer tous les dossiers bin et obj de mes projets et rouvrir Visual Studio.

Nous avons rencontré ce problème et déterminé que le sous-répertoire du profil utilisateur dans lequel ClickOnce déployait notre application devait être corrompu, car nous avons pu déployer l'application avec ClickOnce lorsque vous êtes connecté en tant qu'utilisateur différent sur le même ordinateur. .

Nous avons pu résoudre le problème simplement en supprimant le sous-répertoire de C:\Users\<user>\AppData\Local\Apps sous lequel ClickOnce déployait notre application. Dans notre cas, il s’agissait de C:\Users\<user>\AppData\Local\Apps\2.0.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top