Vous travaillez sur un projet Visual Studio avec plusieurs utilisateurs ?

Question

Je me demande quelle est la meilleure approche pour faire travailler plusieurs utilisateurs sur un projet dans Visual Studio 2005 Professional.

Nous avons une solution avec plusieurs bibliothèques de classes, mais lorsque tout le monde ouvre la solution, nous obtenons constamment l'invite "X a été modifié, recharger/jeter ? L'ouverture d'un seul projet est une alternative évidente, mais je trouve qu'elle est plus difficile à utiliser car vous ne pouvez pas voir certaines des autres classes dans les autres projets de cette façon.

Existe-t-il des directives pour le développement en équipe avec VS2005 Pro ?

Edit : Merci. L'environnement actuel est un peu limité dans le sens où il n'y a qu'un seul PC avec une connexion RDP, mais cela va changer à l'avenir. Je marque la première réponse comme acceptée, mais toutes les réponses sont bonnes :)

Answer 1

Ce dont vous avez besoin, c'est du contrôle de la source.

Vous ne devez absolument pas ouvrir les mêmes fichiers sur le réseau sur plusieurs machines. D'une part, Visual Studio a mis en place des garanties pour vous empêcher de modifier certains fichiers au cours d'une construction, mais il n'a rien qui puisse empêcher d'autres personnes de modifier les mêmes fichiers sur le réseau.

En mettant en place le contrôle de la source, chaque développeur aura une copie séparée des fichiers localement sur sa machine de développement, et communiquera périodiquement avec le système de contrôle de la source pour vérifier/commettre les changements. Ensuite, les autres développeurs peuvent demander les dernières mises à jour lorsqu'ils sont prêts à les récupérer.

Answer 2

Utilisez le contrôle des sources pour conserver un dépôt central de tout votre code. Ensuite, chaque utilisateur extrait sa propre copie du code source et travaille localement. Il soumet ensuite uniquement le code qui a été modifié.

https://en.wikipedia.org/wiki/Version_control

Answer 3

Un certain nombre de personnes ont recommandé d'utiliser le contrôle des sources et je suis tout à fait d'accord. Cependant, vous devez également faire ce qui suit.

• Exclure vos fichiers d'options personnelles du référentiel (par exemple vos fichiers .suo).
• Exclure vos fichiers App.config du référentiel. - Pas entièrement, mais vous devez avoir un Template.App.config. Vous commitez ce fichier à la place, et ne copiez votre App.config dans le Template.App.config que lorsque vous faites des changements structurels. Ainsi, chaque utilisateur a sa propre configuration individuelle pour les tests.

Il y a probablement d'autres fichiers à exclure (répertoires d'objets, etc.) mais c'est tout ce à quoi je pense pour l'instant.

Peter

Answer 4

Cela peut paraître narquois, mais si vous ouvrez la solution à partir d'un emplacement partagé, c'est que vous faites quelque chose de mal. Si c'est le cas, vous devriez commencer à utiliser le contrôle de la source (quelque chose comme Subversion) et demander à chacun de récupérer une copie du projet pour y travailler.

Cependant, si vous utilisez déjà le contrôle de la source, il se peut que ce soit le symptôme d'un mauvais archivage. Je trouve que vous n'avez besoin que du sln, et du vcproj sous contrôle de source.

Sinon, je ne sais pas...

Answer 5

Vous devriez vraiment, définitivement travailler avec le contrôle de la source !

Cela permettra d'arrêter les collisions qui se produisent. De plus, si vous apportez des modifications aux projets partagés, cela signifie souvent qu'il est nécessaire de les modifier. es un problème, alors assurez-vous également que tout le code est testé avant d'être enregistré (sinon ils risquent de casser la construction de quelqu'un d'autre), mais assurez-vous qu'ils vérifiez souvent (ou le temps gagné à ne pas traiter les invites sera perdu à fusionner les conflits) :)