Quelle est la meilleure façon de gérer les références dans une application .NET

Récemment, au travail, nous avons rencontré un problème où nous avons tagué / branché un projet et avons eu des problèmes de compilation en raison de références dll / project qui pointaient vers l'ancienne structure de dossiers.

Nous avons créé un dossier «bin externe» pour chacun des projets et copié les DLL référencées dans ces dossiers. Est-ce la meilleure façon ou existe-t-il une norme industrielle spécifique pour gérer cela?

Je dirais que nuget est le meilleur moyen de gérer les dépendances.

NuGet peut gérer les versions et télécharger automatiquement les dépendances de votre locale serveur NuGet.

Il est assez facile de créer / configurer un serveur local. Créez simplement un nouveau projet ASP.NET vide et installez le nuget-serverpackage nuget (à l'aide de nuget;).

Cela signifie également que vous n'aurez pas à archiver toutes les dépendances et / ou gérer leurs versions à l'aide de TFS.

Ce n'est pas vraiment - Microsoft dit que la meilleure façon de gérer les références est de construire votre projet dans une seule solution énorme. Oui, je sais, ils le pensent vraiment aussi.

L'équipe des modèles et des pratiques a rassemblé ses meilleures pratiques en ce qui concerne TFS, mais cela s'applique aux versions générales. Il existe 3 types de configuration de solution, la "1 grande solution", une approche partitionnée qui ressemble beaucoup à la façon dont la plupart des gens géraient les builds en construisant tour à tour et en copiant les artefacts dans un répertoire commun (qui n'est pas aidé par .NET pas ayant un chemin d'accès «inclure» ou «bibliothèque» à l'ensemble du serveur pour faire référence), et une configuration de solution multiple qui est une version plus complexe de celle partitionnée.

Ils disent

In general you should:

    Use a single solution strategy unless the resulting solution is too large to load into Visual Studio.
    Use multiple solutions to create specific views on sub-systems of your application.
    Use multiple solutions to reduce the time it takes to load a solution and to reduce build time for developers.

Pour TFS, ils recommandent de ramifier tous les projets externes à l'intérieur de votre projet, plutôt que de s'appuyer sur le mappage de l'espace de travail qui s'apparente davantage aux externes de subversion. Personnellement, je pense que leurs conseils ne sont pas les meilleures pratiques, mais je suppose qu'ils essaient de minimiser les problèmes de build que vous obtiendrez en utilisant des références.

J'ai eu des problèmes avec les builds .NET qui tentent de raccourcir le système en ne construisant que ce qui est nécessaire, une build nocturne qui fait tout, et copier chaque nouvel assemblage dans un répertoire était le meilleur moyen pour tout le monde de rester synchronisé - en particulier les testeurs. Notez que cela ne s'applique vraiment qu'aux applications .NET, celles C ++ ont tendance à fonctionner car elles n'ont pas d'assemblys versionnés ou d'aspects similaires qui peuvent causer des problèmes avec les composants appelants. Cette approche fonctionne bien, mais vous ne pouvez pas toujours supposer que les versions partielles sont correctes, vapoter le tout et reconstruire est le plus sûr.

Cela dépend de la structure de votre solution et des capacités de votre logiciel de contrôle de version. Auparavant, nous avions l'habitude de conserver un projet non construit / ignoré dans nos solutions qui contenait de la documentation et un dossier spécifiquement pour toutes les bibliothèques référencées par des tiers. Comme il faisait partie de la solution, le chemin d'accès à ces fichiers pouvait être référencé à l'aide du chemin d'accès relatif. Après avoir migré vers TFS 2010, nous nous sommes débarrassés de ce projet et avons simplement ajouté un répertoire "Support" dans le dossier de cette solution dans le projet d'équipe parallèlement à nos branches principales. Dans les deux cas, la version de contrôle de la source de la bibliothèque finit par être au même endroit relativement indépendamment de la façon dont les développeurs ont configuré leurs machines.

Lorsque vous utilisez subversion pour le contrôle de version, vous pouvez utiliser la propriété "externals" à cet effet. Cela vous permet de conserver une copie locale d'une DLL partagée dans un chemin relatif à proximité de votre projet actuel. Cela facilite la référence à cette DLL par un chemin de fichier relatif qui ne change pas, même lorsque vous modifiez le répertoire principal de votre projet dans un dossier différent. Les externes vous permettent également de définir la version ou la révision spécifique à inclure.