Comment gérer différents csproj

Question

Je travaille dans une équipe de cinq. Nous travaillons sur une application C# avec cinq projets cs.

Le problème est que pour chaque csproject, chacun de mes collègues a ses propres idées sur la façon de référencer une DLL; certains voudraient lier par référence de projet, d'autres voudraient lier dans la DLL seulement. Donc, chacun d'entre nous aura son propre csproject.

Je veux que tous les vérifier dans leur csproject; mais étant donné que chaque copie de csproject est différente, il n'y a pas vraiment de mécanisme réalisable pour le faire, n'est-ce pas? Mais si je ne leur demande pas d'enregistrer leur csproject, chaque fois qu'ils ajoutent un nouveau fichier, je dois éditer manuellement mon csproject et c'est très fastidieux, sans parler du fait que cela va bien dans le sens d'une intégration continue.

Y at-il une stratégie pour gérer cela? Je sais qu'il serait préférable d'appliquer une norme, mais y a-t-il d'autres options qui laissent de côté?

Il y a une raison pour laquelle la teneur en csproject est différent pour tout le monde; tout le monde n'a pas tous les cinq csprojects, et pas tout le monde peut avoir tous les 5 projets cs. Donc, invariablement, certains devront finir par devoir référencer des DLL au lieu de projets, et certains veulent de se référer aux projets pour faciliter le débogage. Si je devais appliquer une norme, comme le suggèrent les réponses ici, je devrais résoudre ce problème. En ce qui concerne les raisons pour lesquelles nous devons diviser en plusieurs csprojects, c'est parce que nous voulons réutiliser certaines parties du code pour d'autres applications, et parce que tout le monde ne peut pas avoir tous accès au code source. C'est plus politique que technologique.

Answer 1

Votre problème est pas comment gérer avec contrôle de code source.

Votre problème est que vous (ou de gestion) a besoin pour obtenir votre équipe à adopter un ensemble de normes suit toute l'équipe.

Si vous laissez tout le monde suivent leur propre méli-mélo d'idées et ne reçoivent pas la cohésion d'équipe sur les bases, il ne se terminera en larmes ...

Answer 2

Vous êtes certainement résoudre le mauvais problème. Si vous utilisez les fichiers .csproj pour répondre à vos préférences, vous encourez du travail supplémentaire et vous présentez la probabilité d'erreurs, exactement pour la raison que vous décrivez: chaque fois qu'Alice ajoute un fichier à AlicesX.csproj, Bob doit en apprendre davantage. et ajoutez le même fichier à BobsX.csproj.

Vous avez vraiment besoin de considérer cela comme un problème de normes et de la dynamique de l'équipe: accord sur la façon dont les DLL seront référencées dans les sources de maître, et exigent que tout le monde en tenir à cela. Si le côté «perdant» n'aime pas travailler de cette façon, bien sûr, ils peuvent utiliser leur style préféré dans leurs copies de travail privées. Mais vous ne voulez qu'une seule source maîtresse, et vous voulez travailler à ce que tout le monde achète comme le fait la source maîtresse.

par votre édition: Si vous avez vraiment, vraiment ne peut pas parvenir à un accord avec vos collègues, alors je encore suggérer un seul maître, mais écrire un petit utilitaire que les contestataires peuvent utiliser qui convertit les références de projet à des références DLL (ou vice versa). Les fichiers .csproj ne sont que du XML donc c'est assez trivial à faire. Si vous ne pouvez même pas vous mettre d'accord sur le format du référentiel, vous devrez alors gérer des fichiers .csproj parallèles, mais j'écrirais tout de même l'utilitaire pour que les modifications apportées à DllReferencingProj.csproj soient copiées dans ProjectReferencingProj.csproj.Mais je dis toujours que vous faites plus de travail et que vous accumulez plus de douleur que si vous aviez la querelle et que vous en finissiez avec: pour fonctionner en équipe, vous allez devoir trouver un moyen de résoudre différends, et c'est aussi bon que le cas de test comme tout.

Answer 3

Il est temps de faire grandir tout le monde et de suivre une norme. Si vous travaillez tous sur le même code, vous devez décider ensemble si le référencement de la dll ou du projet est le meilleur, puis respectez-le. Une fois que vous avez compris cela, vous pouvez décider d'indenter 2 ou 4 espaces ou un onglet. Décidez ensuite si vous souhaitez placer vos accolades sur la même ligne ou sur la ligne suivante après vos déclarations de fonction. Je ne vais même pas parler aux caprices de la notation hongroise ...

Answer 4

L'intégration continue ne devrait pas se préoccuper de vos fichiers .csproj. Je suppose qu'ils sont des fichiers MSBUILD? Ou quelque chose? Ne les utilisez pas pour CI.

Ils sont indésirables. Ils accumulent des déchets parce qu'ils rendent trop de choses invisibles. Créer une structure de construction propre qui est indépendante d'eux, vous en serez reconnaissant. Et puis vérifiez seulement dans un fichier de projet lorsque vous ajoutez quelque chose, et tout le monde peut mettre à jour/fusionner. Vous n'avez pas besoin d'avoir le même ou même des fichiers de projet similaires la plupart du temps. Dans mon équipe, nous n'utilisons même pas la même version de VS sur tous les postes de travail.

Answer 5

Notre configuration est la suivante:

• Projet -> dll copie au dossier commun
• du projet -> copier dll dans le dossier commun
• Projet principal -> Copie exe dans le dossier commun, application d'exécution À partir du dossier commun

Peu importe comment vous référencez en utilisant cette configuration, les DLL seront récupérés à partir du dossier de l'application et vous êtes en or.