Discussion :

[EricLCH]

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 c# :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[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.

[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)

[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 !!

[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

[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 !

[tomlev]

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

Ah bon ? pourtant je le fais tout le temps...
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 :

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"

[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 ...

[tomlev]

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...

[EricLCH]

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.

[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.
___________________________________________________________

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

[tomlev]

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

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