Discussion :

[Lebeb]

Bonjour à tous !

Je suis un développeur en vb.net dans une entreprise Suisse. Nous développons des solutions pour les pharmacies. C'est à dire caisse enregistreuse et tout le tralala qui va avec.

On utilise Visual Studio 2005 et VB.Net, donc Framework 2.
Dans notre solutions nous avons environs 95 projects imbriqués (control, dll ect..) dans la solution explorer.

Mais permettez moi de me plaindre un petit peu ! VS 2005 est d'une lenteur, à jetter sa machine à chaque compilation, à chaque modification de code, par la fenêtre...

Pourquoi à chaque fois que l'on ouvre une form GUI, un petit symbôle (un plus avec un engrenage) s'affiche et va savoir ce que le compilateur fait...
Bref, je sais pas si d'autre personne souffre de se problème de rapidité....

Avez-vous trouver des astuces ? Qu'elle sont vos expériences avec VS ?

Merci de me faire partager vos expériences

Bonne journée

[Xno]

Salut,

C'est vrai que VS2005 requiert quand même pas mal de ressources par rapport à la version précédente mais, pour moi avec 512Mo de RAM, ça reste acceptable. En même temps, je n'ai jamais eu à mettre 95 projets dans une seule solution...

Ce problème de lenteur est peut-être du à un manque de mémoire RAM. La solution serait alors de scinder en plusieurs solutions ta solution principale. J'ai par exemple développé une bibliothèque de classes et de fonctions dont je me sers dans tous mes projets .NET, mais je n'inclus pas le projet de cette librairie dans mes solutions, sinon cela recompilerait tout à chaque fois...d'où une perte de temps.

[Kelpan]

Bonjour,

Nous sommes en VS 2003 et nous avons une solution qui contient 27 projets.

Avant le le SP1 de 2003, nous bricolions des solutions réduites ou des solutions indépendantes pour chaques projets.

Depuis le patch, nous n'avons plus de fausses erreurs de compilation qui nous obligeaient à regénérer la solution complète.
Nous bossons donc avec la solution complète, mais avec des compilations personnalisées.
Ex : Dans le gestionnaire de configuration, tu créés une nouvelle config (Work, par exemple), mais par contre dans les contextes de génération tu pointes tous les projets sur le dossier "Debug"
Tu décoches l'option générée pour tous tes projets, sauf le projet de démarrage.
Si tu as activé la génération incrémentielle sur tous tes projets, tu auras toutes tes dll, dans le bin qui seront récopiés seulement en génrérant le projet de démarrage.
(Nous avons gardé l'option Debug pour une génération complète de la solution, car il reste toujours quelques problèmes qui surviennent après un certain temps d'utilisation)

Ensuite quand tu fais une modification, il ne te reste plus qu'à regénerer le projet que tu as modifié. (c'est plus rapide)
C'est un habitude à prendre et c'est vrai qu'au début, on se prends la tête à savoir pourquoi la modif qu'on vient d'effectuer ne fonctionne pas, pour se rendre compte qu'on a oublié de regenerer le projet...

Par contre 95 projets dans une solution me semble énorme.
Je te conseille de créer des solutions pour les dll stables (controles de bases, écrans de bases, acces aux données, administration, ...) et de les ajouter en référence sur tes projets de travail.

J'espère avoir pu t'aider

[Marc Lussac]

Les conseils proposés cvi dessus sont en effet très judicieux.

Lebeb, vous avez combien de RAM ?

Si c'est aussi lent sur votre machine c'est peut etre que ca swappe, et si ca swape c'est par manque de RAM.

D'autre part si vous travaillez sur des projets trop gros pour votre machhine, il faut en effet décomposer votre projets en sous projet et créer des "composants" pour diminuer de façon considérable la taille de chaque composants, ce qui de toute façon est la seule solution pour développer de gros projets de façon fiable et évolutive.

[Kelpan]

2 Go de RAM
Processeur 3GHz
(J'ai quand même un serveur SQL qui tourne en local, pour le moment)

[Piotrek]

On avait deja ce probleme avec 2003, le probleme c'est que visual basic compile en arriere plan.

Cependant pour Visual Studio 2005, il y a un bug qui a l'air de corser le tout:
http://support.microsoft.com/?kbid=917452

Enfin, 95 projets distincts dans une meme solution c'est vriaiement beuacoup! Je pense qu'il serait bon de profiter de cette migration pour rationnaliser l'application en plusieur solutions.

Un dernier mot: une migration automatique de code est tout sauf parfaite, il faut absolument prendre en compte toutes les nouveautes de VB7+
Improving .NET Application Performance and Scalability
et
http://msdn.microsoft.com/vbrun/stay...s/default.aspx
section migration applications