Est-il possible de travailler sur le même assemblage dans différents projets dans .Net?

Question

Je suis curieux de savoir comment les gens travaillent dans de grandes équipes de développeurs.

Je travaille seul, et chaque fois que je crée un nouveau contrôle, je crée un nouveau projet pour conserver tous les fichiers associés.

J'ai plusieurs assemblages auxiliaires communs que j'importe mais, pour la plupart, des commandes distinctes sont conservées dans des projets distincts. Je me demande si, quand les développeurs travaillent sur, disons, System.Windows.Forms, ils travaillent tous sur le même projet, ou sur des projets séparés qui sont tous fusionnés ensemble à un moment donné.

Si elles sont fusionnées ensemble plus tard, -

(1) Comment cela se fait? (2) Existe-t-il un moyen de marquer une classe comme publique mais de lui dire de passer à l'ami une fois qu'il a été fusionné?

De même, lors de l'expédition d'un produit particulier, est-ce que beaucoup de temps est consacré à l'extraction, à la fusion et à l'internalisation des classes pour le produit fini?

BTW, j'utilise l'édition express.

Answer 1

La clé à ceci est le contrôle de source.

Chaque projet dans une solution est indépendant dans le contrôle de source. Lors de la configuration de votre solution, utilisez la fonction de liaison de votre système de contrôle de source pour que toutes vos solutions utilisant un projet spécifique soient renvoyées au même endroit. Si vous devez apporter une modification à un projet partagé entre différentes solutions, cette modification est validée dans votre référentiel et vous la mettez à jour dans votre autre solution avant de continuer à travailler.

Vous ne voulez jamais vous mettre dans une situation où vous fusionnez des projets. Les solutions Visual Studio peuvent avoir plusieurs projets. Cela dit, vous voudrez probablement regrouper des contrôles individuels afin que des éléments similaires soient dans le même projet, plutôt que d'avoir un seul contrôle par projet. Si vous ne souhaitez pas conserver les fichiers associés, vous pouvez utiliser des dossiers dans le projet.

Answer 2

Bien sûr, j'ai souvent plusieurs solutions différentes qui utilisent les mêmes assemblages, ou qui utilisent différents sous-ensembles des assemblages dans le même "espace de solution". Un par exemple, est d'avoir une solution qui a référencé projet d'assembly inclus en tant que projet (afin que je puisse déboguer dedans) et une autre solution qui a juste comme référence dll, où je ne suis pas intéressé par le débogage dedans .

Answer 3

Je pense que le problème ici est la "création d'un nouveau projet pour chaque contrôle" - cela me semble être une mauvaise idée. Devoir fusionner plus tard est une douleur. Il est vrai que VS aggrave les choses en ayant à lister les fichiers dans le projet - cela signifie qu'il existe un point de fusion fréquent dans le contrôle de source - mais que des centaines de projets minuscules ne semblent pas évolutifs pour moi.

Travailler avec d'autres personnes sur un même projet peut également avoir des inconvénients, mais dans l'ensemble, je dirais que vous devez déterminer où votre code est logique et en faire la structure du projet - ne basez pas votre code sur votre équipe structure et qui se trouve à faire le travail.

Answer 4

Je suis d'accord que c'est typiquement où le contrôle de source entre, mais si vous travaillez vraiment séparément et que vous voulez développer sur un projet séparé en dehors du contrôle de la source, vous pouvez toujours assemblées liées.

Il est vraiment facile à utiliser et peut fusionner les assemblages séparés que les gens travaillent ensemble en un seul assemblage avec une commande sur la ligne de commande.