Où placez-vous vos bibliothèques tierces?

Il n’y a pas d’endroit standard pour les mettre, mais assurez-vous de:

• Mettez-les au même endroit
• Incluez-les dans le contrôle de source.

J’ai mis toutes les dll requirejses dans un répertoire de niveau supérieur de ma solution appelé “Dépendances”, parallèlement aux dossiers du projet. Je les ai dans le contrôle de code source de telle sorte que lorsque de nouveaux développeurs testent la solution, tout est compilé et fonctionne immédiatement. C’est la seule façon de faire.

Je n’inclus que les fichiers .dll absolument nécessaires. Cela rest léger, ce qui est bon, mais quand je trouve une autre partie de MVC Consortingb ou ce dont j’ai besoin, je dois aller chercher le répertoire décompressé, qui peut-être même pas sur mon ordinateur! D’autres ont placé des répertoires de bibliothèque entiers (readme.txt et tous) dans le cadre de leur contrôle de source lié à la solution. Cela garantit que vous et les futurs développeurs auront tout ce dont ils ont besoin, mais ajoute un peu de poids mort. Soit une bonne stratégie.

Avoir un dossier “Lib” au même niveau que les projets source est une méthode courante.

Pour être honnête, ce ne sont pas les dépendances de mes projets que je trouve difficile à gérer, ce sont les dépendances des dépendances. Je voudrais juste mentionner NHibernate, Castle Windsor et les diverses installations de Castle Windsor en particulier. Obtenir tous ceux qui jouent ensemble sur mon dernier projet m’a pris beaucoup de temps.

Pour les projets open source, j’aime aussi avoir le code source à scope de main car il est parfois utile de le déboguer dans le code source. (Et parfois parce que la documentation est très pauvre, vous devez lire le code source pour savoir comment ça marche). J’ai vu des projets de VS disposés de manière à ce que le projet fasse référence à la DLL, mais en même temps, VS sait où trouver le code source. Pendant que j’écris, je ne me souviens plus très bien comment le faire.

Ainsi, un dossier Lib pour les DLL fonctionne pour moi; Je l’appelle souvent “Dépendances partagées”.

En ce qui concerne le code source open source, je n’ai pas de méthode standard pour la version car chaque projet est structuré différemment et comporte un processus de construction différent. Je n’aime pas bricoler la structure de projet open-source ou la méthode de construction, car j’en assume la responsabilité. Si pour une raison quelconque, il ne construira pas, ou construira de manière incorrecte, ou produira une DLL défectueuse, la cause sera extrêmement difficile à localiser, et je devrai me plonger dans le dépannage de tout ce dont je ne me soucie pas. tout.

Dans un dossier SOUS votre répertoire de solution, par exemple “externe” ou “bibliothèque”. Ainsi, votre système d’continuous integration (ou d’autres membres de l’équipe) peut extraire une racine de votre système de contrôle de source et disposer de tout ce dont ils ont besoin.

En SVN, utilisez svn: externals pour extraire ce répertoire à partir d’une autre racine afin de pouvoir facilement partager des DLL de bibliothèque (et des projets de bibliothèque) entre des solutions.

Au bureau, nous avons un partage sur le réseau pour les utilisateurs référencés. Il peut s’agir de tierces parties ou d’assemblées partagées entre les projets.

Je n’aime pas non plus l’idée de placer les fichiers DLL dans le contrôle de code source. Si tous les développeurs ont access au partage, tout fonctionnera correctement.

Le répertoire de Visual Studio dans My Documents semble être un endroit logique pour les mettre. Je ne sais pas si c’est le meilleur ou quelque chose qui cloche, mais au moins toutes les bibliothèques se trouvent au même endroit.

 %USERPROFILE%\My Documents\Visual Studio XXXX\Libraries 

Dans mon entreprise, nous plaçons tous nos assemblys DLL partagés sur un lecteur réseau dans un dossier appelé Assemblies. À partir de là, nous utilisons SyncToy pour mettre en miroir les modifications entre ce dossier et un dossier sur nos machines de développement locales (dans mon cas, C: \ Assemblies avec des sous-dossiers pour différentes versions ou des assemblys tiers utiles). L’utilisation de la fonctionnalité “Chemins de référence” des projets Visual Studio facilite la sélection de différentes versions d’assembly en fonction des emplacements.

Pour les projets à la maison, je voudrais certainement aller avec l’idée mentionnée par Jeff M de les placer dans le dossier Visual Studio sous My Documents .

Je n’ai pas de règle ssortingcte sur l’emplacement. Cependant, j’encourage la cohérence !

Par exemple, je devais faire cela pour un petit outil que je suis en train d’écrire pour un client, alors j’ai vérifié leurs autres bases de code dans Bitbucket qui semblaient utiliser un dossier de dépendances dans le dossier de la solution (à côté des autres projets), alors j’ai copié ça.