C# 2008 et seven 64 bits

Version imprimable

12/02/2011, 16h16
EricLCH

C# 2008 et seven 64 bits
Bonjour,

J'ai installé C# 2008 express sur un PC équipé de windows seven 64 bits. L'installation en elle même s'est bien déroulée mais je me retrouve face à un comportement étrange lors de l'utilisation. En effet le débugger ne semble pas fonctionner et de plus le système semble de lui même passer outre les erreurs présentes.

Exemple de code devant générer une erreur :

J'ai créé un nouveau projet windows form et j'ai créé ce petit bout de code dans la fenetre.
Code:

1 2 3 4 5 6 7 private void Form1_Load(object sender, EventArgs e) { int R; R = int.Parse("W"); }
L'affectation de la variable R doit générer une erreur mais ce n'est pas le cas : la fenêtre s'ouvre comme si de rien n'était !
De temps en temps j'ai un message d'erreur indiquant que svhost.exe a cessé de fonctionner mais c'est tout.
Si quelqu'un a une idée je suis preneur parce que là je bloque !
Pour info, histoire de me faire une idée, j'ai installé visual C# 2010 et j'y retrouve exactement le même problème.
Merci d'avance
12/02/2011, 17h22
sevyc64

Concernant l'erreur, je ne saurais pas dire. mais concernant le debugger c'est normal.

Tu es sur une plateforme 64bits, ton projet est compiler par défaut vers la cible "Any CPU", cela signifie que sur une plateforme en 64bits, celui-ci fonctionnera en 64bits.

Or il n'est pas possible de debugger une application 64bits avec Visual Studio.

Si tu veux debugger ton projet, il faut que tu force la compilation en 32bits (CPU cible : x86), là, le debugger acceptera de fonctionner.

Le CPU cible se change dans les paramètres du projet, mais je ne sais pas trop où, l'accès diffère entre la version Express et les versions complètes.
12/02/2011, 17h56
Pol63

+1

pour la version express c'est dans les fichiers de projet qui sont en xml qu'il faut rajouter un truc voir avec google pour le détail (plateforme cible c# express)
12/02/2011, 19h18
EricLCH

Merci pour vos réponses,

J'ai trouvé où spécifier les options du débugger mais malgré ça je n'ai toujours pas d'erreur de signalée lorsque je tente le code présenté au premier message.

Pour information sous C# 2008 les options du compilateur se définissent par le biais du menu "Outils\Options". Dans la fenêtre qui s'ouvre il faut cocher la case "Afficher tous les paramètres" située en bas. Ensuite il faut aller sur "Projet et solution" et cocher la case "Afficher les configurations de génération avancées". Une fois cela fait une barre d'outils supplémentaire est ajoutée permettant de définir les options de génération.
Il est également possible de placer la commande "/platform x86" dans la case "Symboles de compilations conditionnelles" de l'onglet "Générer" de la fenêtre "Propriété" du projet.

Mais malgré tout pour l'instant rien de tout cela ne marche !!
12/02/2011, 19h43
Pol63

essaye de placer ce code dans le click d'un bouton pour voir si ca plante, et vérifie aussi que tu passes bien dans le void (avec un messagebox avant et après par exemple)

tu peux aussi regarder les paramètres du compilateur à tout hasard

en vb.net que le form load ne plante pas ca ne me choquerait pas, mais en c# ca serait plus étrange
12/02/2011, 20h49
EricLCH

Bonne idée Pol63 !!

Lorsque je place le code dans le code d'un bouton le debugger refonctionne et ce même si je n'active pas la fonction x86 du compilateur !!

As-tu une explication à cette bizarrerie ??

Encore merci pour ton aide !
12/02/2011, 21h02
Pol63

j'ai déjà vu ce comportement sur vb.net
l'explication que j'en avais c'est que vb.net est plus axé débutant et qu'une form qui plante ca embête un débutant ^^
ayant analysé un peu le comportement, le code sort à la ligne qui plante (la suite n'est pas exécuté) mais ca ne plante pas

peut etre que ce comportement est lié à la version express, qui plus orienté débutant aussi en théorie

je viens de regarder dans reflector et la méthode onload (qui déclenche l'évènement) n'a pas de try catch englobant ... je ne suis pas remonté à la source des appels, donc il y a en peut etre un peu haut, c'est une hypothèse possible ...

il y a de nombreuses choses aussi étranges sur vb.net (même sur les versions payantes) qui servent à aider les débutants mais qui au final ne les aident pas

par contre dans le constructeur ca plante dans tous les cas
et de toute facon une des choses à faire pour éviter les soucis c'est de mettre des try catch dans les membres public et les gestions d'évènements, avec tracage de l'erreur

je vais dire à un pro de passer par là, peut etre aura-t-il une explication rationnelle ...
12/02/2011, 21h40
tomlev

Citation:

Envoyé par sevyc64

Or il n'est pas possible de debugger une application 64bits avec Visual Studio.

Ah bon ? pourtant je le fais tout le temps... :koi:
Le debugger marche très bien en 64 bits, ce qui ne marche pas c'est la fonctionnalité "edit & continue"

Pour revenir au problème, je ne vois rien d'anormal. Une erreur dans le Load n'est pas fatale, elle n'empêche pas le programme de continuer. Mets un breakpoint au début du Load et exécute en pas à pas, tu verras que le debugger fonctionne bien. A priori ce comportement est lié à Windows Forms et non à C#, donc ça doit faire pareil en VB.

Quand tu exécutes dans le debugger, ça logge juste l'erreur dans la fenêtre Sortie :

Citation:

Une exception de première chance de type 'System.FormatException' s'est produite dans mscorlib.dll

Si tu veux que le debugger s'arrête dès qu'une exception se produit, il faut changer une option dans Déboguer -> Exceptions, cocher la checkbox dans la colonne "Levé" sur la ligne "Common Language Runtime Exceptions"
12/02/2011, 22h13
Pol63

avec le même code

dans un bouton_click => vs signale qu'il y a une erreur et pointe la ligne (hors vs ca s'arrêterait)
dans le form_load => ca log juste l'erreur et ca continue

moi je trouve ca étrange ...
12/02/2011, 23h15
tomlev

Citation:

Envoyé par Pol63

avec le même code

dans un bouton_click => vs signale qu'il y a une erreur et pointe la ligne (hors vs ca s'arrêterait)
dans le form_load => ca log juste l'erreur et ca continue

moi je trouve ca étrange ...

je suppose que dans le cas du Load l'erreur est interceptée quelque part...
13/02/2011, 16h31
EricLCH

Citation:

Envoyé par tomlev

Si tu veux que le debugger s'arrête dès qu'une exception se produit, il faut changer une option dans Déboguer -> Exceptions, cocher la checkbox dans la colonne "Levé" sur la ligne "Common Language Runtime Exceptions"

J'ai fais cette mdif de configuration et effectivement maintenant le debugger s'arrête sur l'erreur lorsque le code est placé dans le load. Il ne l'indique toutefois pas de la même manière, une petite flêche verte est présente et on peut poursuivre l'exécution du code. Par contre si du code est placé après la ligne générant l'erreur il n'est pas exécuté.
Ce qui est également étrange c'est que C#2008 installé sur XP SP3 génère bien une véritable erreur.

En tout cas merci pour votre aide précieuse.
21/02/2011, 09h58
EricLCH

Bonjour à tous,

J'ai également posé la question sur ce comportement de Seven 64bits sur le forum MSDN de Microsoft et voici la réponse que j'ai reçu.
___________________________________________________________

Citation:

Cette exception est due aux différences entre la plateforme de debug x86 et x64. Pour x64, la même exception est générée, mais on a un try-catch pour le code d’initialisation, qui permet de gérer cette exception en silence, sans fermer l’application. Pour x86, cette gestion n’existe pas, et l’erreur cause la fermeture de l’application.

Un bug est déjà signalé sur Connect concernant ce comportement :

https://connect.microsoft.com/Visual...pment-machines

________________________________________________________

Le problème est donc connu de Microsoft et ce depuis 2008. A priori il n'y a aucune indication sur une éventuelle correction prochaine de ce bug.

Cordialement,

EricLCH
21/02/2011, 13h03
tomlev

bien vu, j'avais même pas envisagé que ça puisse être un bug ;)

Citation:

Envoyé par EricLCH

Le problème est donc connu de Microsoft et ce depuis 2008. A priori il n'y a aucune indication sur une éventuelle correction prochaine de ce bug.

Si, il y a un hotfix, regarde dans les commentaires du bug sur Connect
21/02/2011, 14h42
EricLCH

C'est exact sauf que la solution proposée ne semble pas corriger le problème comme l'indique le dernier message du forum. J'essaierai toutfois la solution proposé histoire de voir.
J'ai reçu aujourd'hui un nouveau message de microsoft qui m'indique que pour l'instant il n'y a pas de solution. Le problème est à l'étude et un correctif devrait être proposé par contre ils n'ont pas la moindre idée de la date de sortie de ce correctif.