pour VS 2005 existe-t-il un nombre maximal de projets pouvant entraîner des problèmes de performances. Nous avons maintenant jusqu'à 25 projets et en croissance. Devrions-nous faire ces références binaires ou allons-nous sortir notre logique d'application dans trop de projets différents. Semble commencer à être un gros problème de performance ces derniers temps.Le plus grand nombre de projets au sein d'une solution
Avoir trop de fichiers DLL peuvent vous coûter à l'exécution donc je vous recommande d'essayer de minimiser la quantité de projets. La création de plusieurs solutions est également une option, mais essayez de rendre les solutions indépendantes l'une de l'autre afin de ne pas devoir déboguer et implémenter de nouvelles fonctionnalités sur plusieurs solutions, ce qui peut être fastidieux.
Jetez un oeil à cet article: Project anti-pattern: Many projects in a Visual Studio Solution File.
Je dirais que cela vous coûte au moment de la construction et non pas à l'exécution. Et moins c'est plus rapide, mais peut-être que vous ne les construisez pas toujours tous. Si c'est le cas, vous devriez réduire le montant. d'autre les diviser en différentes solutions. Seul le serveur de build devra construire tous et une construction quotidienne a toute la nuit pour construire ;-)
Y at-il une chaîne de dépendance à travers l'ensemble des 25 projets? Si certains projets ne dépendent pas des autres, mettez-les dans leur propre solution.
Ne compilez pas la totalité de la solution si ce n'est pas le cas et ce n'est généralement pas le cas. Habituellement, vous pouvez faire un clic droit sur le projet que vous venez de modifier et compiler juste cela. VS déterminera quels projets dépendants doivent être recompilés. Utilisez "démarrer sans débogage" sauf si vous prévoyez d'atteindre un point d'arrêt.
Certaines DLL sont-elles stables et n'ont pas changé depuis longtemps? Ils n'ont pas besoin d'être dans votre solution non plus.
Ne recherchez pas la solution complète à moins d'y être obligé.
La véritable limite est l'esprit humain. Combien de fichiers dans un projet peut-on traiter? En outre, à moins que vous n'utilisiez ndepends pour tracer des dépendances, la mise à plusieurs classes dans un projet peut entraîner un trop grand nombre de classes en fonction des autres classes, ce qui rend les changements plus difficiles et plus risqués.
Normalement, nous essayons de garder la quantité de projets au sein d'une solution sous 10. Après 10, vous commencez à avoir le temps de compilation lent et lent « reload projet » temps.
Mais le principal problème ici est pourquoi avez-vous 26 projets? Un simple site Web ne peut contenir qu'un seul projet tout en conservant le niveau de données, le niveau métier et le niveau de présentation dans le même projet.
Si vous fractionnez les projets que pour ce genre de choses 3 niveaux, je suggère que vous révisez cela. à titre d'exemple, nous avons 3 projets pour le niveau 3. La raison pour laquelle nous avons 3 niveaux dans l'assemblage séparé est que nous exisons d'autres logiciels pour utiliser le niveau de données plus tard dans notre projet. Garder notre couche d'affaires en dehors du projet de présentation principal nous permet de tester facilement notre niveau métier tout en conservant des dépendances inutiles en dehors du niveau présentatier.
Ainsi, dans l'ensemble, maintenir les projets de moins de 10 et si vous pouvez revoir fusionner certains projets togheter. Cela vous permettra à la fois de gagner du temps au moment de la compilation ET au moment de la construction. Il sera également plus facile de gérer ces DLL.