Où stocker les fichiers DLL externes?

Dans mon projet, j’utilise des bibliothèques tierces. Je les inclut en utilisant le dossier de références dans Visual Studio.

Mais où dois-je enregistrer les fichiers DLL? Ils sont référencés à partir d’un chemin dans le système de fichiers, mais ce serait bien si je pouvais l’inclure dans le projet. Mais comment?

C’est ce que je fais:

  • Créez un dossier lib au niveau de la solution
  • Téléchargez et copiez tous mes fichiers DLL tiers
  • Référence du dossier lib
  • Placez tous ces fichiers DLL dans le contrôle de source . J’utilise Subversion et je les ajoute manuellement, mais c’est unique.

Vous pouvez également append un dossier de solution et les append ici.


MISE À JOUR 2012-12-19

La réponse ci-dessus était quand NuGet était en bas âge. FWIW, mon approche où nous avons des articles NuGet:

  1. Faites comme ci-dessus pour les dépendances de fichiers DLL simples (où ils n’ont pas de pkg NuGet)
  2. Activer la “restauration de package” pour la solution
  3. Modifiez le fichier packages.config si nécessaire pour verrouiller la version à un package particulier
  4. Ne pas stocker le paquet lui-même dans le système de contrôle de version (définir ignorer pour Git , Mercurial , etc.)

En fait, j’utilise NuGet pour gérer même les dépendances internes et avoir un stream privé.

En règle générale, la structure de mes projets ressemble à ceci (au minimum):

 projectname - trunk - src - lib - support - docs - releases 

Le dossier de lignes contient la copie de la source sur laquelle je travaille actuellement. De plus, il y a un répertoire ‘lib’ qui contient tous les assemblys tiers référencés par mon projet.
(Je référence les assemblages à cette position).

Le dossier ‘releases’ contient des twigs du tronc. Par exemple, lorsque la version 1 est publiée, une twig du tronc est prise afin de disposer d’une copie du code source et de toutes ses dépendances nécessaires pour générer la version 1 de l’application. (Ceci est pratique pour les corrections de bogues. Corrigez le bogue dans cette twig, fusionnez le correctif dans le tronc, reconstruisez cette twig et vous avez un v1 fixe de votre application).

Toutes ces choses entrent dans le contrôle des sources. (Oui, les assemblages référencés également). Ce faisant, il est très facile si un autre collègue doit également travailler sur le projet. Il obtient juste la dernière version du contrôle de source, et il (ou elle) a tout en place pour pouvoir comstackr et construire.

(Notez que cela est également vrai si vous utilisez quelque chose comme CruiseControl pour une continuous integration ).

Dans la fenêtre des propriétés de Visual Studio pour la référence à la DLL, il y a une propriété appelée ‘Copy Local’ – définissez-la sur true, et elles seront copiées dans le répertoire bin de votre projet local.

Jetez un coup d’oeil à NuGet (gestionnaire de paquets pour Visual Studio) …

NuGet est une extension de Visual Studio qui facilite l’installation et la mise à jour des bibliothèques et des outils open source dans Visual Studio.

Lisez ensuite ce document NuGet pour obtenir la crème de la crème :

Utiliser NuGet sans valider les paquets au contrôle de la source

Vous devriez regarder NuGet . C’est une extension de gestion de package pour Visual Studio 2010 conçue exactement pour ce que vous voulez.

Regardez Tree Surgeon – Crée une arborescence de développement pour un projet .NET, ce qui peut être un bon sharepoint départ et à partir de là, vous pouvez improviser.

Personnellement, j’ai un dossier dans mon contrôle de source pour les DLL tierces (avec un dossier pour chaque société, organisation) et les référence à partir de là.

Ces fichiers sont alors disponibles pour tous les développeurs qui téléchargent la source et peuvent être facilement mis à jour.

Pour y répondre correctement, vous devez faire la différence entre l’ environnement et le poste de travail .

Environnement:

  • Ce sont tous les outils et bibliothèques nécessaires pour créer votre solution.
  • Les choses dans l’environnement devraient restr raisonnablement constantes.
  • Les choses dans l’environnement sont généralement versionnées et vous devriez pouvoir avoir plusieurs versions côte à côte.
  • Les choses dans l’environnement sont généralement autorisées.
  • L’environnement n’est pas sous le contrôle de la source.
  • Un bon exemple serait Visual Studio.

Ensemble de travail:

  • C’est essentiellement votre code source.
  • C’est toutes les conditions requirejses pour accéder à votre exécutable final.
  • Vous devez vous attendre à ce que le poste de travail change beaucoup pendant le développement.
  • Le jeu de travail doit être sous contrôle de source.

Vous devez décider dans quelle catégorie correspond votre composant.