Meilleure pratique pour stocker et référencer les bibliothèques DLL?

Souvent, un développeur de mon équipe va créer un nouveau projet Visual Studio et référencer une DLL quelque part sur leur machine locale (par exemple, C:mydllshomersimpsontest.DLL). Ensuite, lorsque je reçois le projet à partir du référentiel de contrôle de source, Je ne peux pas construire le projet car je n'ai pas la dll référencée au même emplacement sur ma machine.

Quelle est la meilleure pratique pour stocker et référencer les bibliothèques partagées?

21
demandé sur Daniel Mann 2008-12-22 06:21:02

7 réponses

Je crée généralement un dossier lib dans mon projet, où je mets les dll référencées. ensuite, je pointe la référence à la dll dans le dossier lib. De cette façon, chaque développeur peut construire le projet après avoir récupéré du contrôle de source.

Si c'est un projet qui a été construit en interne, vous pouvez également ajouter ce projet à votre solution.

18
répondu Travis Collins 2008-12-22 03:37:07

La meilleure pratique que je m'attends à ce que votre référentiel SC inclue et applique les emplacements relatifs des objets référencés pour vous (généralement via un chemin partagé), de sorte que vous ne traitez pas directement ce problème. Le développeur d'origine doit vérifier ces informations.

4
répondu dkretz 2008-12-22 03:33:41

Si l'assembly n'est pas dans le GAC, créez un répertoire appelé dependencies et ajoutez-y tous les assemblys. Le dossier et les assemblys sont ajoutés au contrôle de source. La règle est que, compte tenu de tout projet de contrôle de source, tout ce qui est nécessaire pour construire est de faire une extraction et la construction du projet (ou exécuter certains outil qui est également vérifié dans le projet).

Si vous ajoutez un dossier à la solution et ajoutez les assemblys au dossier de la solution, cela fournit également un repère visuel aux développeurs cela indique quelles dépendances externes sont présentes... toutes les dépendances sont dans ce répertoire. Les chemins relatifs garantissent que Visual Studio peut localiser les références sans problème.

Pour les grandes solutions, avec plus de 20 projets, cela rend la vie beaucoup plus facile!

4
répondu Shim Tait 2014-06-25 20:08:26

Si vous vérifiez les DLL réelles dans le contrôle de source, vous pouvez les référencer par chemin relatif et tous les développeurs obtiendront automatiquement toutes les dépendances lors de la prochaine mise à jour du projet.

L'ajout d'une référence DLL par chemin complet serait une erreur de développeur tout comme l'ajout d'un fichier source par chemin complet serait une erreur.

2
répondu Greg Hewgill 2008-12-22 03:38:57

Rule of thumb : si le projet ne fait pas partie de la solution, référencez les DLL libérées à partir d'un répertoire /binshare ou /lib contrôlé par la source qui se trouve sous l'arborescence de contrôle de source de votre solution. Toutes les dépendances externes doivent avoir des dll versionnées qui vont dans ce répertoire / binshare.

Je comprends ce que votre collègue fait en ce qui concerne la commodité. Cependant, l'approche de ce développeur est diamétralement opposée à une gestion de configuration/construction appropriée.

Exemple: Si vous utilisez le bloc D'Application MS Data en tant que dépendance dans votre application, vous devez référencer un binaire correctement publié, au lieu d'obtenir les dernières informations du tronc source de développement de MS.

1
répondu Daniel Auger 2009-10-30 19:37:35

Je pense que cette approche est tout à fait le contraire de ce que je considérerais comme la meilleure pratique. Je pense que ce serait une bien meilleure approche de garder les binaires tiers hors du référentiel source et de les référencer à travers quelque chose comme un référentiel Maven dans votre processus de construction. Mettre les DLL dans le référentiel source gonfle inutilement le contenu du référentiel et entraîne des projets prenant beaucoup plus de temps que nécessaire. Il rend également la gestion indépendante de les versions des binaires tiers sont obscurcies en ne faisant pas référence à la version par son nom, mais plutôt en faisant référence à la dll d'une version particulière stockée dans le dossier projects lib.

0
répondu Maury Richards 2011-02-23 23:04:48

Pourquoi ne pas mettre en place un flux NuGet privé? De cette façon, il n'y a qu'une seule copie d'une dépendance (le référentiel NuGet) et plusieurs projets peuvent La référencer. Plusieurs versions de la dépendance peuvent coexister, et chaque projet peut référencer une version différente, si nécessaire. En outre, TFS Build peut restaurer les paquets au moment de la construction.

Configuration de VS: https://www.visualstudio.com/en-us/docs/package/nuget/consume

0
répondu Janiek Buysrogge 2018-01-05 05:36:50