Discussion :

[ben_popcorn]

Bonjour,

J'ai un soucis plutôt gênant avec une solution développée sous VS2005 sur un PC biprocesseur, 2.5Go de RAM, bref une belle bête qui fait des jaloux dans ma boîte ^^
Depuis un mois, à quasiment chaque modification de code/génération, devenv.exe occupe 100% du processeur (en fait 50% d'un des 2 proc) sur un temps infini ... Je ne récupère pas la main sur Visual Studio. Par contre j'ai quand même la main sur le reste de mes applis (merci le biproc).
Ma solution est connectée à un serveur SourceSafe que j'ai mis en cause. Mais même une fois déconnecté du VSS le problème persiste.
Ce qui est étrange c'est que cette même solution fonctionne sur les autres postes des développeurs de cette solution...J'ai aussi essayé une déconnexion totale du réseau, mais ça ne change rien.
J'ai tenté enfin de passer sous Visual Studio 2008, mais c'est toujours pareil.

J'ai trouvé une solution de dépannage en récupérant un vieux portable mais c'est pas le pied...

quelqu'un a-t-il des idées/pistes à suivre/solutions ?

Merci d'avance
Ben

[lysiandad]

Bonjour,

Votre equipement devrait clairement vous permettre de developper dans des conditions tres confortables... Vous avez deja identifié le probleme, qui est donc une surconsommation du temps CPU sur cette solution particulière. C'était bien la première étape. Le coupable est donc probablement un composant (présent dans la toolbox VS ou non) ou une librairie / un package / un add-in activé lorsque vous ouvrez votre solution "tueuse".

La seconde étape, c'est d'utiliser vos connaissances/compétences en matière de debug sous Visual Studio, et en l'espèce, de savoir surveiller/auditer les threads, la pile d'appel, les modules chargés, etc, dans une application .NET : en êtes vous familier ?

Si c'est le cas, vous trouverez surement interessant de savoir que depuis Visual Studio 2005 au moins, vous avez la possibilité de faire du debug de Visual Studio et de ses designers, etc, à partir de... lui même.

Eh oui.

Cela s'appelle le mode "experimental". Je ne vais pas rentrer dans plus de details, mais VS peut donc fonctionner avec un arbre de clés (dans la base de registre) parallèle au mode standard, appelé le "experimental Hive".

La mise en oeuvre est assez simple.

Lisez d'abord ceci :

http://msdn.microsoft.com/en-us/libr...60(VS.80).aspx

Cela concerne VS 2005, mais on trouverez la meme chose pour VS 2008.

Installez donc le VS 2005 SDK, depuis ici :

http://www.microsoft.com/downloads/d...displaylang=en

(note : je vous recommande, si ce n'est deja fait, d'avoir applique le VS 2005 SP1 avant ; mais bon, le VS 2005 SDK fonctionne quand meme sans le SP1)

Ensuite, en ligne de commande (ou via un raccourci) lancer ceci (adaptez les chemins a votre installation) :

"D:\Program Files\Microsoft Visual Studio 2008 SDK\VisualStudioIntegration\Tools\Bin\VSRegEx.exe" GetOrig 9.0 Exp

Puis, en utilisant une solution "bidon" (avec un seul projet quelconque, même "vide", mais executable), positionner pour les proprietes de debug quelque chose proche de ce screenshot :

http://dotxml.brinkster.net/pour.dev..._exp_debug.jpg

"Start external program" doit indiquer le chemin d'acces vers ce cher devenv.exe (l'exe de l'EDI Visual Studio)

"Command line arguments" : se termine par le chemin vers la solution "a problème" ; notez la valeur magique "Exp" que j'ai entouré en rouge au debut, qui apparait egalement dans la ligne de commande donnée ci-dessus, trois paragraphes plus haut ( "... GetOrig 9.0 Exp" ).

Puis, depuis ce mode standard de VS, faites F5 : cela lancera la deuxieme instance de VS en mode "experimental" en ouvrant votre solution "tueuse", qui sera en session de debug, et vous permettra de l'auditer a partir du premier VS (celui en mode standard).

J'ai utilisé cette technique, avec succès bien sûr, plusieurs fois, pour depister des bugs "bêtes et méchants" dans certains de mes composants (ou d'autres, tierce partie) qui me posaient problème en mode design dans des Winforms, par exemple.

Bon courage, "bonne chance".

N'oubliez pas de dire "merci" aux equipes de dév MS de Visual Studio et de son SDK si vous vous en sortez...

'HTH

Bonjour,

J'ai un soucis plutôt gênant avec une solution développée sous VS2005 sur un PC biprocesseur, 2.5Go de RAM, bref une belle bête qui fait des jaloux dans ma boîte ^^
Depuis un mois, à quasiment chaque modification de code/génération, devenv.exe occupe 100% du processeur (en fait 50% d'un des 2 proc) sur un temps infini ... Je ne récupère pas la main sur Visual Studio. Par contre j'ai quand même la main sur le reste de mes applis (merci le biproc).
Ma solution est connectée à un serveur SourceSafe que j'ai mis en cause. Mais même une fois déconnecté du VSS le problème persiste.
Ce qui est étrange c'est que cette même solution fonctionne sur les autres postes des développeurs de cette solution...J'ai aussi essayé une déconnexion totale du réseau, mais ça ne change rien.
J'ai tenté enfin de passer sous Visual Studio 2008, mais c'est toujours pareil.

J'ai trouvé une solution de dépannage en récupérant un vieux portable mais c'est pas le pied...

quelqu'un a-t-il des idées/pistes à suivre/solutions ?

Merci d'avance
Ben

[ben_popcorn]

Merci pour cette réponse détaillée
Je vais explorer tout ça, y a du boulot

[ben_popcorn]

Ok, j'ai mis le système en place.
Mais question naïve, comment faire des breakpoint ? Est-ce une notion qui a du sens dans ce genre de procédé ?

J'ai oublié de précisé que le pb de CPU intervient aussi quand je fais une modification de code que je sauve...l'icône de sauvegarde (disquette clignotante dans la status bar) flashe quelques secondes puis plus rien et le CPU grimpe en flêche...

[lysiandad]

Oui, vous pouvez poser des breakpoints, bien sûr, dans un source (C#, VB.NET, etc) d'un composant impliqué dans un des projets de la solution qui "tue". Mais bien sûr, n'ayant pas d'info sur l'architecture / les technos utilisée dans celle-ci, ne l'ayant pas sous les yeux, il est difficile, comme ça, de vous dire a priori où mettre ce(s) breakpoint(s)...

Utilisez votre intuition sur ce qui est impliqué quand vous sauvegarder tout ou partie de cette solution ; si nécessaire, procédez par "dichotomie" en qq sorte et excluez les projets un par un par... ou excluez les de la compilation/du build... ou excluez certains sources, etc

A nouveau, bon courage, "bonne chance".

C'est clairement un problème que vous devez adresser assez rapidement de toute façon, je suppose...

Ok, j'ai mis le système en place.
Mais question naïve, comment faire des breakpoint ? Est-ce une notion qui a du sens dans ce genre de procédé ?

J'ai oublié de précisé que le pb de CPU intervient aussi quand je fais une modification de code que je sauve...l'icône de sauvegarde (disquette clignotante dans la status bar) flashe quelques secondes puis plus rien et le CPU grimpe en flêche...

[ben_popcorn]

Bon, j'ai fai du ménage dans ma solution et il me reste juste un projet WinForms (l'IHM de mon appli).
Je suis désolé mais j'ai du mal à comprendre comment je peux débugger la sauvegarde d'un fichier source par Visual Studio
La montée du CPU n'intervient pas au RuntIme de mon projet mais bien pendant l'édition sous VS2005.

Ma solution initiale (l'appelante) ne contient le minimul syndical (1 formulaire vierge) , me trompe-je ?

Merci en tout cas de votre aide