Comment emballez-vous les bibliothèques externes dans vos projets .Net?

Question

Beaucoup de mes projets contiennent la pile Castle/NHibernate/Rhino-Tools. Ce qui est déroutant, c'est que Castle dépend de certaines bibliothèques NHibernate, NHibernate dépend de certaines bibliothèques Castle, et Rhino-Tools dépend des deux. J'ai construit les trois projets sur ma machine, mais je pense que la copie des bibliothèques NHibernate/Castle est un peu redondante depuis que j'ai construit Rhino-Tools en utilisant les bibliothèques résultantes de mes builds NHibernate et Castle.

À l'heure actuelle, j'inclus tous les projets dans des dossiers séparés dans mon dossier/thirdparty/libs dans mon arborescence de projet. Devrais-je simplement avoir/thirdparty/libs/rhino-tools dans mon projet et utiliser les librairies Castle/NHibernate à partir de là? Cela semblerait logique de ne pas dupliquer les fichiers, mais j'aime aussi avoir chaque projet dans son propre dossier distinct.

Quelle est votre opinion à ce sujet?

Answer 1

J'utilise un dossier pour chacun, ce qui semble être la convention.

1. Est-ce que cela fait vraiment une différence si vous les copiez?
2. Et si vous voulez en désactiver un? Disons que vous allez avec un nouveau mappeur O/R. Il sera beaucoup plus facile de simplement supprimer le dossier NHibernate que de supprimer sélectivement les DLL dans votre dossier Rhino-Tools.
3. Prenez ce à sa conclusion logique et vous pas l'organisation des dossiers dans votre dossier lib puisque tout utilise log4net :)

Answer 2

Ajouter chemins de sondage supplémentaires à vos fichiers app.config pour localiser les dll de dépendance. De cette façon, vous pouvez obtenir une copie de tout ce que vous voulez. Bien qu'il y ait quelques bizarreries à utiliser cette fonctionnalité (vous devez créer la structure de dossier d'une certaine manière). Regardez here pour plus de détails sur l'étiquette.

Answer 3

Je vais certainement recommander d'avoir un dossier tiers ou fournisseur dans chacun de vos arbres de projet. Si vous trouvez ennuyeux d'avoir 32 copies du paquet rhino-tools, vous pouvez en avoir une copie unique dans votre dépôt de code, et y faire des références externes dans votre arborescence de projet. Supposons que vous utilisiez SVN, vous pouvez créer un dépôt appelé "thirdparty libs" et avoir des versions des bibliothèques. Vous créez ensuite une propriété externe sur votre dossier "thirdparty" dans votre arborescence de projet, puis vous effectuez automatiquement une vérification de vos bibliothèques tierces centralisées. De cette façon, vous ne devez par exemple mettre à jour en un endroit qu'une sécurité ou une correction de bogue, mais chaque projet contrôle toujours les bibliothèques tierces et les versions à utiliser. A propos de la deps en interne dans les bibliothèques tierce partie, je ne me dérangerait pas ceux-ci. La première fois que vous compilez votre projet et que certaines bibliothèques ne sont pas copiées dans votre dossier bin à cause de dépendances implicites, vous pouvez ajouter un attribut externe dans votre dossier bin, qui vérifiera automatiquement les bibliothèques manquantes. De cette façon, vous n'avez plus qu'à mettre à jour vos bibliothèques tierces en un seul endroit.

Answer 4

C'est l'un des problèmes que nous essayons de résoudre dans le Refix open source project on CodePlex. L'idée est que Refix analyse tous les projets dans votre solution, et avant que votre projet compile, copiez les binaires nécessaires d'un seul dépôt local sur votre machine dans un dossier dans l'arbre de solution et pointez les projets sur eux. De cette façon, il n'y a pas besoin de valider les binaires. Votre référentiel Refix local extrait les binaires d'un dépôt distant (nous en installons un à la repo.refixcentral.com), et vous pouvez en créer un intermédiaire pour votre équipe/département/entreprise qui peut contenir tout logiciel supplémentaire non centralisé.

Il tentera également de résoudre en conflit les numéros de version - Visual Studio peut être trop pardonner des numéros de version des composants ne correspondent pas, ce qui conduit à des solutions qui compilent mais tombent sur au moment de l'exécution quand ils ne parviennent pas à charger une dépendance parce que deux versions différentes serait nécessaire. Donc, pour répondre à la question «comment emballez-vous les bibliothèques externes dans vos projets .Net», notre vision est que vous n'avez pas - vous n'avez qu'à inclure une étape Refix dans votre script de construction, et laissez-la s'inquiéter pour toi.