2009-12-02 6 views
3

ExempleComment structurer des applications entières dans Visual Studio?

Je travaille sur le projet, qui ont 3 parties distinctes (ASP.NET MVC, WinForms, Silverlight) et 15 projet (commune, Api, Services, dépôt et Cabs WinForm).

Résolutions

1) Tout ce projet dans une solution
2) Pour chaque partie ont la solution

Quelle est la meilleure façon de traiter avec des solutions et projets dans Visual Studio?

Tout d'abord, c'est génial si je refactoring.
La deuxième est bonne pour une meilleure clarté.

Répondre

1

Je fais les deux. Vous pouvez ajouter un projet à plusieurs solutions.

+0

J'ai rencontré un problème avec cette configuration. Si vous ajoutez une référence à un projet dans la même solution et que vous placez le projet référencé ALSO dans une autre solution ... La référence du projet dans la première solution sera brisée. C'est ce qui m'est arrivé. (VS 2008) –

+0

Je n'ai jamais eu de problèmes comme celui-ci. – GvS

+0

Je suis d'accord avec @GvS, je n'ai jamais eu le problème d'un projet corrompu étant hébergé dans plus d'une solution. – kenny

0

Ma préférence est de créer des projets partagés dans une zone globale et de les ajouter dans des configurations d'applications spécifiques (solutions) si nécessaire. Les projets non partagés, spécifiques à une solution, peuvent vivre dans cette solution. Gardez simplement à l'esprit que les modifications apportées à un projet partagé dans une solution affecteront ce projet dans toutes les autres solutions qui l'utilisent.

0

Naturellement est une solution par application (exe ou hébergée n'a pas d'importance). Ensuite, placez tous les assemblages que vous déboguez souvent ou refactorisez.

Autres fichiers conservés en tant que fichiers binaires compilés.

0

Je voudrais avoir une solution pour chaque partie, ce qui signifie que chaque ASP.NET MVC, Silverlights et Winform a son propre fichier .sln. En ce qui concerne le refactoring, cela ne devrait pas poser de problème car si vous avez Resharper installé, au moment où vous refactorisez le code dans d'autres solutions, vos fichiers cs de csprojects non mis à jour seront rayonnants de couleur rouge (sans compilation) , et vous pouvez simplement le renommer en un clic (Modifier toutes les options xxx en yyy)

0

Ma préférence est de n'avoir qu'un seul fichier de solution, puis de créer des dossiers de solution sous chacun (Services, Commun, Présentation, etc.). Ensuite, sous le dossier Présentation, créez des dossiers distincts pour Web, Windows, Silverlight. Chaque projet serait placé dans le dossier approprié.

Pour moi, c'est l'approche la plus simple pour tout garder sous un même toit. Plus facile à compiler, à partager des ressources et à gérer le contrôle des sources. Donc, une solution typique pour moi pourrait avoir 15 - 20 projets différents dans l'arbre, en fonction de la complexité de la solution.

0

Je pense effectivement que le premier serait meilleur pour la clarté. La raison en est qu'il est plus facile de dire si vous modifiez un projet partagé pour MVC si le compilateur vous crie dessus pour le projet WinForm. De plus, vous devriez être en mesure de régler le débogueur de sorte que lorsque vous cliquez sur Déboguer, il déboguera uniquement le projet sélectionné (sélectionnez le MVC, WinForm ou Silverlight avant de cliquer sur le bouton de débogage). Cela facilite le débogage de MVC, Winform et Silverlight sans avoir à modifier les paramètres de débogage.

1

En fonction de la taille des différents projets, j'utiliserais une solution unique pour tous les projets. Je ne mets jamais de projets dans des dossiers de solution, réserve des assemblages partagés, lit des fichiers, etc.

Je suggère de créer un SolutionInfo.cs dans le dossier Éléments de solution et d'y ajouter une référence dans tous vos projets. Vous pouvez ensuite supprimer la plupart des attributs d'assembly dans les fichiers AssemblyInfo.cs. J'ai seulement 3 attributs dans AssemblyInfo: AssemblyTitle, AssemblyDescription, Guid. Les autres propriétés sont partagées entre tous mes projets. Le fait d'avoir tous les projets dans la même solution garantit que vous avez des espaces de noms appropriés et qu'il n'y a pas de collisions entre les différentes implémentations client.

Nommez vos projets en fonction des espaces de noms, par exemple si votre projet s'appelle "Sport", puis nommez la solution "Sport", la bibliothèque partagée pour "Sport.Common", "Sport.Web" et ainsi de suite . Je commence seulement à envisager de séparer les projets dans plusieurs solutions lorsque j'ai des problèmes de performance et que la compilation prend beaucoup de temps. Avoir tout dans la même solution rend la gestion beaucoup plus facile, surtout si vous utilisez un système de contrôle de source.

Questions connexes