Construction C# pour Windows 7 Plate-forme 32 bits sur Windows 7 64 bits

Question

Quelle est la méthode correcte pour créer les programmes d'installation d'une application Windows Forms à installer et à exécuter sur une machine Windows 7 32 bits, à l'aide de Visual Studio 2010 sous Windows 7 machine 64 bits?

Je viens brossai la poussière d'une application 3ans ancienne Visual Studio 2008, construit sous Windows XP, en utilisant SQL Express 2005.

Je l'ai mis à jour à VS2010, SQL Express 2008, et reconstruit sur une machine Windows 7 64 bits. Il doit fonctionner sur une plate-forme Windows 7 32 bits.

Le projet d'installation de la base de données continue à échouer (au démarrage) lors de l'exécution, en disant que c'est uniquement pour une machine x64. (La configuration de l'application s'exécute correctement et s'installe.)

J'ai parcouru tous les projets de la solution et je l'ai configurée pour utiliser x86 (par opposition à Any CPU). J'ai supprimé tous les prérequis. La seule chose qui reste en suspens est un projet DB CustomAction (qui exécute les scripts db). De googling il me semble construire sur une machine 64 bits avec «Any CPU», signifie qu'il devrait produire des fichiers d'installation qui fonctionnera sur une machine 32 bits via WOW? et sans avoir à faire tous les changements que j'ai faits? Est-ce que je manque quelque chose de saignant?

Merci.

Answer 1

Essayez ceci:

• sélectionnez votre projet d'installation dans l'Explorateur de solutions
• vont à ses propriétés volet
• assurez-vous que targetPlatform est réglé sur x86

Answer 2

I Je trouve toujours frustrant de voir les messages de la même question que j'ai jamais eu une résolution affichée. Donc, je vais poster ce que j'ai trouvé au cas où, ou même si elle est utile aux autres un jour. J'ai trouvé beaucoup d'autres développeurs rapportant le message "a cessé de fonctionner" du programme Windows 7 sans but. Par ailleurs, j'ai trouvé le moyen le plus simple de tester le déploiement de l'application et les installateurs étaient de construire une machine Virtual PC avec la même configuration que la plate-forme fonctionnera éventuellement. Ensuite, copiez ce Virtual PC et lancez le test sur la copie. De cette façon, je peux simplement supprimer la copie à tout moment, recopier de l'original et recommencer, rapidement. Oui, comme l'a dit Cosmin, la propriété TargetPlatform de la solution doit également être définie sur x86. Quoi qu'il en soit, n'a pas résolu le problème, l'application a encore produit le message «a cessé de fonctionner».

Ensuite, j'ai vérifié le fichier ERRORLOG des journaux SQL (c: \ Program Files \ Microsoft SQL Server \ MSSQL10.SQLExpress \ MSSQL \ Log) et il signalait que l'application essayait de se connecter en utilisant l'authentification en mode mixte, alors que SQL était défini pour Windows Authenication. Maintenant, je sais que j'ai sélectionné le mode mixte lorsque j'ai installé SQL Express, car mon application utilise un compte de service sql pour lequel mon installateur db crée le compte. Donc en quelque sorte cela a été changé par quelque chose (ne sais pas quoi?). Pour passer en mode mixte via SQL Server Management Studio, cliquez avec le bouton droit de la souris sur l'instance, sélectionnez Sécurité et modifiez l'authentification du serveur. Sans Management Studio, vous devez éditer le registre HKEY_LOCAL_MACHINE/Logiciel/Microsoft/Microsoft SQL Server // MSSQLServer, et éditer la clé LoginMode = 2 pour Mixed. Encore une fois, n'a pas résolu le problème, l'application a encore produit le message «a cessé de fonctionner».Ensuite, par hasard je suis tombé sur quelques messages à propos de ce message peut être causé au démarrage en chargeant des applications 32 bits sur Windows 7. J'ai mis MessageBoxes, et Try/Catchs sur les premières lignes que je pouvais, et ils ne sont jamais affichés et aucune erreur n'a été détectée. La prochaine chose que j'ai essayé était d'exécuter DependencyWalker sur mon exe. Il a signalé 2 fichiers de 32 bits manquants: IEShims.dll et GPSVC.dll. Il ya des messages d'autres développeurs qui rencontrent cela, et le résultat final était je les ai trouvés dans C: \ Windows \ winsxs (GPSVC.dll a été appelé x86_microsoft-windows-g..licy-base.resources_31bf3856ad364e35_6.1.7600.16385_en-us_c10af1bed239c523_gpsvc.dll .mui_0c160ac2). Je les ai déposés dans C: \ Windows \ System32, j'ai recompilé mon application, je l'ai déployée sur ma machine de test, et elle a finalement fonctionné!

Vous ne comprenez toujours pas pourquoi il suffit de les placer dans le répertoire System32 de ma boîte de dev pour faire fonctionner l'application sur la machine de test? Mais de toute façon, cela a réglé le problème, et j'espère que cela aidera les autres.