[Visual Studio] Lenteur au lancement d'applications c#

Bonjour,
J'ai un soucis de lenteur lors du lancement d'applications développées en c# via Visual Studio 2008 et distribuées à partir d'un projet d'installation de Visual

Ce sont de petites appli développées qui devraient se lancer presque instantanément.

Sur ma machine de développement, sous visual, l'exécution est rapide (même avec F5 en mode débug), mais prend plusieurs secondes sur une machine cliente (projet compilé en mode release)

Quelqu'un a-t-il une idée sur ce qui cause cette différence et cette lenteur ?

NB :
- Je développe sous vista, les postes concernés sont sous XP.
- La puissance des pc clients n'est pas à mettre en cause.


Merci de votre aide

Anti-virus sur les clients ?

Le même que chez moi oui.
Si c'est l'antivirus la cause, que faut-il faire ?

Commencez par monter un environnement permettant de voir le problème à tous les coups, cela permettra de vérifier si le problème est résolu quand on aura essayé de le résoudre.:aie:

tu peux utiliser un system.diagnostics.stopwatch pour voir les différences de temps sur la création et l'affichage des formulaires par exemple

si y a une différence de temps c'est que les pcs ne sont pas aussi puissant, et donc peut etre pas assez

enfin sans détail sur la conf des pcs sous xp, et sans code on ne va pas pouvoir t'aider beaucoup ...

Perso, je partirais plus sur le temps de chargement en mémoire du framework ;)

après il est aussi possible de compiler en code natif une fois installé sur le pc du client, voir ngen pour ca

Salut,
merci pour vos réponses.

Concernant ngen, si j'ai bien compris je ne pense pas pouvoir l'utiliser.
En effet, j'utilise un obfuscateur (smartAssembly) qui englobe les dépendances de mon projet et me génère un exe.
C'est cet exe qui est inclu dans le msi qui sert de setup pour les clients. Il n'y a aucun assembly en l'état dans le msi, donc il ne sert à rien de lancer ngen sur le poste client, puisque pas de dll à recompiler.

Sinon j'ai remarqué que la plus grosse partie du temps est perdue dans initializeComponent (de 1 à 5 secondes). Mon formulaire n'est pourtant pas surchargé de composants. J'ai vu quelques optimisations à faire à la main, mais modifier le Designer.cs c'est très contraignant.

peut etre inutile de modifier le fichier designer, celui ci est regénéré en écrasant tes éventuelles modifs en cas de modification !

pour ce qui est de ngen, si ton obfuscateur obfusque le code.net, il doit quand meme le laisser en MSIL, donc recompilation par JIT à chaque exécution
et ngen fonctionne aussi pour des exe, donc il doit fonctionner pour des exe objusqués quand meme

après faut voir la conf de tes pcs clients, et à savoir aussi qu'un exe windows forms fonctionne mieux sous vista/7 que sous xp ...

Citation:

---

Envoyé par Pol63

peut etre inutile de modifier le fichier designer, celui ci est regénéré en écrasant tes éventuelles modifs en cas de modification !

---

C'est bien pour ça que je trouve ça contraignant. Il faudrait être sur que l'interface est définitive, ce qui n'est jamais le cas. C'est pourtant ce qui est expliqué sur la doc msdn

Citation:

---

Envoyé par Pol63

pour ce qui est de ngen, si ton obfuscateur obfusque le code.net, il doit quand meme le laisser en MSIL, donc recompilation par JIT à chaque exécution
et ngen fonctionne aussi pour des exe, donc il doit fonctionner pour des exe objusqués quand meme

---

Ça m'intéresse mais je ne trouve pas de doc claire sur la marche à suivre. Les test que j'ai fais se sont soldés par un échec, j'ai mis ça sur le fait que j'essayais de lui passer un exe en paramètre et un assembly ...

quand on installe paintdotnet (trouvable gratuitement sur le net) il passe beaucoup de temps à l'install pour "optimisation" je pense fortement que c'est parce qu'ngen est appelé directement après la copie des fichiers

j'ai déjà testé ngen, j'avais pas trop galléré il me semble
c'est expliqué entre autre ici : http://msdn.microsoft.com/fr-fr/libr...8VS.80%29.aspx
il faut faire /install chemin_de_l'exe à vu de nez
enfin ca se teste facilement depuis une fenetre de commande avant de l'intégrer dans un setup

La version de Framework est-elle la même?
Certains composants comme les DataGridView sont plus lents en 2.0 qu'en 3.5.

N'arrivant à utiliser ngen, j'ai finalement contourné le problème.

J'ai créé une petit appli bidon, invisible, qui est installée dans le menu "Démarrage". Elle se lance donc au démarrage et règle en partie le problème du temps de chargement à froid.
AutoCAD par exemple semble utiliser ce principe.

Pour info voici les résultats :
Avant : à froid => chargement application 16 sec
à chaud => chargement application 3 sec

Après: à froid => chargement application 6 sec
à chaud => chargement application 3 sec

C'est pas encore optimum mais le gain est déjà conséquent.