J'ai un tas de .dll les assemblages, tels que HtmlAgilityPack y MoreLinq . Où suis-je censé mettre ces fichiers ? Je les jette généralement quelque part dans mon Projects dossier, mais je suis toujours en train de les chercher. Y a-t-il un endroit standard pour les mettre ?
Réponses
Trop de publicités?
IanT8
Points
1165
Il est courant d'avoir un dossier "Lib" au même niveau que les projets sources.
Pour être honnête, ce ne sont pas les dépendances de mes projets que je trouve difficiles à 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 que tout cela fonctionne ensemble sur mon dernier projet m'a coûté beaucoup de temps.
Pour les projets open source, j'aime aussi avoir le code source à portée de main car il est parfois utile de déboguer dans le code source. (Et parfois, parce que la documentation est si pauvre, vous devez lire le code source pour savoir comment cela fonctionne). J'ai vu des projets VS arrangés de façon à ce que le projet fasse référence à la DLL, mais en même temps, VS sait où trouver le code source, alors que j'écris, je ne me souviens plus comment 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 en libre accès, je n'ai pas de méthode standard pour le versionner, car chaque projet est structuré différemment et a un processus de construction différent. Je n'aime pas bricoler la structure d'un projet open-source ou la méthode de construction, car j'en prends alors la responsabilité. Si pour une raison quelconque, il ne se construit pas, ou se construit de manière incorrecte, ou produit une DLL défectueuse, la cause serait extrêmement difficile à trouver, et je devrais me plonger dans le dépannage de tout cela, ce qui ne m'intéresse pas du tout.
Ian Mercer
Points
19271
Dans un dossier SOUS le répertoire de votre solution, par exemple "externe" ou "bibliothèque". De cette façon, votre système d'intégration continue (ou d'autres membres de l'équipe) peut extraire une racine de votre système de contrôle des sources et disposer de tout ce dont il a besoin.
Dans SVN, utilisez svn:externals pour extraire ce répertoire d'un Root différent afin de pouvoir partager facilement les DLLS (et les projets de bibliothèque) entre les solutions.
George Handlin
Points
93
Au bureau, nous avons un partage sur le réseau pour les assises référencées. Il peut s'agir d'assemblages de tiers ou de nos propres assemblages qui peuvent être partagés entre les projets.
Je n'aime pas non plus l'idée de mettre les fichiers dll dans le contrôle de la source. Si tous les développeurs ont accès au partage, tout fonctionnera bien.
Jeff Mercado
Points
42075
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 site Il n'y a rien de mieux ou de mauvais à cela, mais au moins toutes les bibliothèques se trouvent en un seul endroit.
%USERPROFILE%\My Documents\Visual Studio XXXX\Libraries
Matthew Ferreira
Points
5110
Dans mon entreprise, nous plaçons tous nos assemblages DLL partagés sur un lecteur réseau dans un dossier appelé Assemblies. À partir de là, nous utilisons SyncToy pour mettre en miroir les changements entre ce dossier et un dossier sur nos machines de développement locales (dans mon cas C:\Assemblies avec des sous-dossiers pour les différentes versions ou les assemblages tiers utiles). L'utilisation de la fonction "Reference Paths" des projets Visual Studio permet de sélectionner très facilement différentes versions d'assemblages en se basant uniquement sur les emplacements.
Pour les projets à la maison, je suivrais certainement l'idée mentionnée par Jeff M de les placer dans le dossier Visual Studio sous My Documents .
- Réponses précédentes
- Plus de réponses
