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

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.

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!

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.

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.

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.

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