Comment partagez-vous les dépendances externes entre les solutions Visual Studio?

Question

J'ai un arrière-plan Java, j'ai l'habitude que Maven gère tous les problèmes de téléchargement et de mise à jour des dépendances. Mais dans l'environnement .NET, je n'ai pas encore trouvé un bon moyen de gérer toutes ces dépendances externes.

Le problème principal ici est que je produis des solutions en masse et qu'elles ont toutes tendance à dépendre des mêmes DLL tierces. Mais je ne veux pas conserver des copies séparées de chaque composant sous chaque solution. J'ai donc besoin d'un moyen de relier toutes les différentes solutions au même ensemble de DLL.

Je me suis rendu compte qu'une solution pourrait être d'inclure les bibliothèques externes dans un "projet de bibliothèque" qui est inclus dans toutes les solutions et laisser les autres projets les références à travers lui. (Ou assurez-vous simplement de référencer les DLL externes au même endroit pour tous les projets.)

Mais y a-t-il de meilleures façons de faire cela? (De préférence en utilisant une sorte de plug-in pour Visual Studio.)

J'ai regardé le Visual Studio Dependency Manager et il semble être un match parfait, mais quelqu'un l'a-t-il essayé pour de vrai? J'ai également vu les ports .NET de Maven, mais malheureusement je n'étais pas trop impressionné par le statut de ceux-ci. (Mais s'il vous plaît allez-y et recommandez-leur quelqu'un si vous pensez que je devrais leur donner un autre essai.)

Alors, quelle serait la meilleure façon de résoudre ce problème?

Mise à jour:

j'ai réalisé que je devais expliquer ce que je voulais dire avec un lien vers le même ensemble de son dll. L'une des choses que j'essaie de réaliser ici est d'éviter que les différentes solutions référencent des versions différentes de chaque composant. Si je mets à jour un composant vers une nouvelle version, il doit être mis à jour pour toutes les solutions lors de la prochaine génération. Cela me forcerait à m'assurer que toutes les solutions sont à jour avec les derniers composants.

Mise à jour 2: Notez que ceci est une vieille question posée avant des outils tels que NuGet ou OpenWrap existait. Si quelqu'un est disposé à fournir une mise à jour plus à jour, s'il vous plaît allez-y et je vais changer la réponse acceptée.

Answer 1

1. Trouvez un endroit pour stocker les assemblages. Par exemple, je stocke le.ensembles de base net comme si:

   • <branch> \ netfx \ 2,0527 \ *
   • <branch> \ netfx \ 3,0 \ *
   • <branch> \ netfx \ 3,5 \ *
   • <branch> \ netfx \ Silverlight 2 \ *
   • <branch> \ NetFX \ Silverlight 3 \ *

2. Utilisez la propriété ReferencePath dans MSBuild (ou AdditionalReferencePath dans Team Build) pour pointer vos projets sur les chemins appropriés. Pour la simplicité et la facilité de maintenance, j'ai un fichier 1 * .targets qui connaît tous ces répertoires; tous mes projets Importer ce fichier.

3. Assurez-vous que votre stratégie de contrôle de version (branchement, fusion, local < -> mappages de serveur) conserve les chemins relatifs entre vos projets & vos chemins de référence constants.

EDIT

En réponse à la mise à jour dans la question, permettez-moi d'ajouter une étape supplémentaire:

4) Assurez-vous que toutes les références de montage dans chaque fichier projet utilise le nom complet forte .Net et rien d'autre.

Bad:

<Reference Include="Microsoft.SqlServer.Smo"> 
    <SpecificVersion`>False</SpecificVersion> 
    <HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server\100\Shared\Microsoft.SqlServer.Smo.dll</HintPath> 
</Reference> 

Bon:

<Reference Include="Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" /> 

Avantages du dernier format:

• L'utilisation d'un HintPath dans un environnement de développement collaboratif conduira inévitablement à des situations où « il travaille pour moi "mais pas les autres. Surtout votre serveur de construction. L'omettre vous force à corriger vos chemins de référence ou à ne pas les compiler.
• L'utilisation d'un nom faible invite la possibilité de "DLL enfer". Une fois que vous utilisez des noms forts, vous pouvez avoir plusieurs versions du même assemblage dans vos chemins de référence, car l'éditeur de liens n'en charge que ceux qui correspondent à tous les critères. De plus, si vous décidez de mettre à jour certains assemblages (au lieu d'ajouter des copies), vous serez averti de toute modification de rupture au moment de la compilation au lieu de à chaque fois que les bogues commencent à arriver.

Answer 2

Je habituellement une structure de dossier séparé sur le contrôle de code source pour les dépendances extrenal ou internes, et ces filders ont les assemblées selon la construction ou le numéro de version par exemple

public \ externe \ bibliothèques \ Nunit \ 2.6 \

ou

public \ interne \ bibliothèques \ Logger \ 5.4.312 \

et à l'intérieur des solutions tous les projets qui ont besoin d'utiliser l'une des dépendances ajoute simplement une référence à cette Assem blies dans les dossiers publics internes ou extrenal.

Answer 3

Ajoutant à ce que tout le monde dit, il se résume à deux choses:

1. Faire en sorte que tous les développeurs ont les mêmes versions des bibliothèques externes
2. Faire en sorte que tous les développeurs ont les bibliothèques externes situées au même endroit (au moins, par rapport au code source)

Comme le souligne Richard Berg, vous pouvez utiliser ReferencePath et/ou Additi onalReferencePath pour aider à résoudre # 2. Si vous utilisez msbuild dans votre processus de construction (dans notre cas, nous utilisons CruiseControl au lieu de MS Team Build), vous pouvez également lui passer ReferencePath sur la ligne de commande. Pour résoudre # 1, j'ai trouvé svn:externals pour être utile (si vous utilisez SVN). Mon expérience avec Maven est que c'est beaucoup trop pour la plupart des usages.