Travailler avec des bibliothèques communes/utilitaires

Question

Dans l'entreprise pour laquelle je travaille, nous avons un projet "Utilitaire" qui est référencé par presque toutes les applications que nous construisons.Il contient beaucoup de choses comme NullHelpers, ConfigSettingHelpers, Common ExtensionMethods, etc.

Notre façon de travailler est que lorsque nous voulons créer un nouveau projet, nous obtenons la dernière version du projet à partir du contrôle de source, l'ajoutons à la solution, puis référençons le projet à partir de tout nouveau projet ajouté à la solution.

Cela a bien fonctionné, mais il y a eu quelques cas où des personnes ont apporté des « modifications radicales » au projet commun, ce qui fonctionne pour eux, mais ne fonctionne pas pour les autres.

J'ai pensé qu'au lieu d'ajouter la bibliothèque commune comme référence de projet, nous devrions peut-être commencer à développer la bibliothèque commune en tant que DLL autonome, publier différentes versions et cibler une version particulière pour un projet particulier afin que des modifications puissent être apportées sans aucun risque. à d'autres projets utilisant la bibliothèque commune.

Cela dit, je suis intéressé de voir comment les autres référencent ou utilisent leurs bibliothèques communes.

Answer 1

C'est exactement ce que nous faisons.Nous avons un projet utilitaire qui possède des fonctions utiles non spécifiques au projet.Nous augmentons la version manuellement (mineure), construisons le projet en version Release, le signons et le plaçons dans un emplacement partagé.

Les gens utilisent alors la version spécifique du bibliothèque.

Si certaines méthodes utiles sont implémentées dans certains projets spécifiques et pourraient se retrouver dans le projet utilitaire principal, nous les plaçons dans une classe d'assistance spéciale dans le projet et les marquons comme candidats utilitaires possibles (simple //TODO).A la fin du projet, nous examinons les candidats et s'ils collent, nous les déplaçons vers le principal bibliothèque.

Les modifications radicales sont interdites et nous marquons les méthodes et les classes comme [Obsolètes] si nécessaire.

Mais cela n’a pas vraiment d’importance car nous augmentons la version à chaque publication.

J'espère que cela t'aides.

Answer 2

Nous utilisons le branchement dans le contrôle de source ;tout le monde utilise la branche head jusqu'à ce qu'il fasse une version.Lorsqu'ils créeront une branche sur la version, ils créeront également une branche sur le projet d'utilitaires communs.

De plus, notre projet d'utilitaires possède ses propres tests unitaires.De cette façon, les autres équipes peuvent savoir si elles interrompraient la construction d’autres équipes.

Bien sûr, nous avons encore des problèmes comme vous le mentionnez de temps en temps.Mais lorsqu'une équipe apporte une modification qui interrompt la construction d'une autre équipe, cela signifie généralement que le contrat pour cette méthode/objet a été rompu quelque part.Nous considérons cela comme des opportunités pour améliorer la conception du projet de services publics communs...ou au moins pour écrire plus de tests unitaires :/

Answer 3

j'ai eu le EXACT même problème!

J'avais l'habitude d'utiliser des références de projets, mais tout semble mal tourner, alors que, comme vous le dites, vous avez de nombreux projets qui y font référence.

Je compile maintenant dans une DLL et définit la propriété CopyLocal pour la référence DLL sur false après la première construction (sinon, je trouve que cela peut remplacer les sous-projets et simplement devenir un gâchis).

Je suppose qu'en théorie, cela devrait probablement être GAC, mais si c'est un problème qui change beaucoup (comme le mien), cela peut devenir problématique.