Erreur Visual Studio : “The following module was built either with optimizations enabled or without debug information”

Un collègue est tombé sur ce problème ce matin en voulant débugger un service.

Remarque : Cette boite de dialogue est généralement accompagné d’un nom de dll/exe. Elle a été enlevé ici de la copie d’écran.

Apparemment Visual Studio n’arrive pas à rentrer en mode DEBUG. Dans ce cas là, plusieurs choses à vérifier tout de suite :

1. Vérifier l’onglet Build du fichier csproj du projet concerné (indiqué par le nom de la dll).

• Vérifier que votre configuration est bien sur “Debug”
• Vérifier que la case “Optimize code” est décoché (même en Debug, on ne peut pas débugger du code optimisé).
• Vérifier que le résultat de la compilation va bien dans le répertoire que vous souhaitez (Output Path)
• Cliquer sur le bouton “Advanced” et vérifier que “Debug Info” est sur “Full”.

2. Dans le répertoire de sortie du projet, vérifier que la DLL est bien accompagné d’un fichier pdb du même nom. Ce fichier contient les symboles permettant le debug de l’assembly. Si ce n’est pas le cas, faites un “clean project” puis “Build Project”. Ces fichiers devraient apparaitre.

2bis. Si ce n’est toujours pas le cas,voir point 4.

3. Vous avez un fichier pdb dans votre répertoire de sortie mais pas dans le répertoire où est utilisé votre assembly. Un test rapide est de copier le pdb dans le répertoire où est utilisé l’assembly et lancer l’application (F5). Si cela fonctionne, passer au point 4 pour automatiser la copie.

4. Depuis Visual Studio, supprimer la référence de la dll incriminée des projets puis rajouter la de nouveau. Un petit Clean/Rebuild Solution devrait tout faire rentrer dans l’ordre.

Je ne sais pas exactement la raison de ce problème.Apparemment “sans raison”, Visual Studio conserve une ancienne version de la dll et/ou ne transfère pas les fichiers pdb. Dans le cas de mon collègue, le point 4 a permis la résolution du problème.

En espérant que ce post aidera des gens. Si quelqu’un à une explication sur la raison du non transfert des fichiers pdb, je suis intéressé.

Erreur 404 lors d’un Debug d’un projet ASP.NET en utilisant “ASP.NET Development Server” sur localhost pour Vista

Bon, le titre est un peu long pour un post aussi court mais il s’agit des mots clés que j’ai mis dans Google pour résoudre un bug qui m’empêchait de bosser depuis quelques temps (d’où le peu de post sur ce site récemment).

Lorsque je travaillais sur un projet ASP.NET (Silverlight ou autres), je me prenais systématiquement une page d’erreur 404 au lancement du débogage. J’étais sûr à 99.99 % que cela ne venait pas de mes projets car je les utilisait depuis plusieurs mois sans problème.

Après de longues recherches (car très peu de posts parlent de ce problème), j’ai trouvé le blog de Accidental Technologist et sur celui de Information for Technology qui indiquent que cela vient d’un bug/problème sous Vista avec les adresses IPv6 pour localhost.

La Solution :

Modifier le fichier hosts dans le répertoire C:\Windows\System32\drivers\etc.

Remplacer

::1             localhost

par

:::1             localhost  (si vous êtes en IPv6)

127.0.0.1             localhost  (si vous êtes en IPv4)

 

Cette solution m’a permis de visualiser ma page sous IE.

L’explication :

Je n’ai pas trouvé d’explication exacte quant à ce problème mais je vais vous donner ma reflexion :

en IPv4, l’adresse localhost est 127.0.0.1.

Avec l’arrivée de l’IPv6, on obtient l’adresse localhost suivante : 0:0:0:0:0:0:0:1

Or d’après la norme IpV6, on peut supprimer les 0 quand il y en a : 0:0:0:0:0:0:0:1 => :::::::1  (7 caractères ‘:’ et un caractère ‘1’)

Toujours d’après cette norme. Si plusieurs ‘:’ se suivent, on peut les remplacer par un seul au début et un seul à la fin donc  :::::::1 => ::1

Lorsque l’on tape dans IE, la chaine suivante : http://[::1]/ .On retombe bien sur la page localhost.

Deux questions me viennent donc à l’esprit :

1°) Pourquoi rajouter un ‘:’ dans le fichier host (Sachant que d’après la norme :  ::1 == :::1 == 0:0:0:0:0:0:0:1 et que ::1 est bien localhost dans la norme) ?

2°) Que s’est-il passé sur mon ordinateur pour que ce problème apparaisse alors que mes projets fonctionnaient correctement à l’origine (Problème détecté la première fois le 10/03/09) ?

Si vous arrivez à répondre à l’une de ces questions, n’hésitez pas à poster en commentaire :). Je continue à chercher de mon coté et je mettrais à jour ce post si je trouve.

EDIT 11/03/09 12h27 : Apparemment pas le seul dans ce cas, car j’ai reçu ce mail  il y a quelques minutes (venant un Microsoft Student Partner dont je vais taire le nom 🙂 ) :  “je voulais savoir si tu avais déjà eu des problèmes avec Cassini, parce que là il ne veut plus m’afficher aucune page que ce soit sur un site ASP.Net MVC, ou ASP.Net classique.”.

EDIT 11/03/09 15h00 : Il semble qu’une mise à jour de Windows Defender aurait modifier le fichier hosts entrainant des bugs sur les sites ‘localhost’