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

Question

Je possède un arrière-plan Java, donc & # 8217; je suis habitué à ce que Maven traite 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é le moyen de gérer toutes ces dépendances externes.

Le problème principal ici est que je produis en série des solutions qui ont toutes tendance à dépendre de la même tierce partie. dll & # 8217; s. Mais je ne veux pas & # 8217; conserver des copies séparées de chaque composant dans chaque solution. J'ai donc besoin d'un moyen de relier toutes les solutions différentes au même ensemble de dll & # 8217; s.

J'ai compris qu'une solution consisterait peut-être à inclure les bibliothèques externes dans un & # 8221; projet de bibliothèque & # 8221; cela est inclus dans toutes les solutions et laisse les autres projets les référencer à travers elle. (Ou veillez simplement à référencer les dll externes & # 8217; s du même endroit pour tous les projets.)

Mais existe-t-il de meilleures façons de le faire? (Utilisez de préférence une sorte de plug-in pour Visual Studio.)

J'ai & # 8217; J'ai consulté le Gestionnaire de dépendances de Visual Studio et cela semble parfait. Match, mais est-ce que quelqu'un l'a réellement essayé? J'ai & # 8217; j'ai également vu les ports .NET de Maven, mais je n'ai malheureusement pas été très impressionné par le statut de ceux-ci. (Mais s'il vous plaît allez-y et recommandez-les à tout le monde si vous pensez que je devrais leur donner un nouvel essai.)

Alors, quel serait le moyen le plus intelligent de s'attaquer à ce problème?

Mise à jour:

J'ai réalisé que je devais expliquer ce que je voulais dire par relier au même ensemble de dll & # 8217; s .

L’une des choses que j’essaie de faire ici est d’éviter que les différentes solutions référencent différentes versions de chaque composant. Si je mets à jour un composant vers une nouvelle version, il devrait être mis à jour pour toutes les solutions lors de la prochaine génération. Cela me contraindrait à m'assurer que toutes les solutions sont à jour avec les derniers composants.

Mise à jour 2: Notez qu'il s'agit d'une vieille question posée avant des outils tels que NuGet ou OpenWrap existait déjà. Si quelqu'un souhaite fournir une information plus à jour, n'hésitez pas, je modifierai la réponse acceptée.

Answer 1

1. Trouvez un endroit pour stocker les assemblages. Par exemple, je stocke les assemblys de base .Net comme suit:

   • <branch > \ NetFX \ 2.0527 \ *
   • <=> > \ NetFX \ 3.0 <=> *
   • <=> > \ NetFX \ 3.5 <=> *
   • <=> > \ NetFX \ Silverlight 2 <=> *
   • <=> > \ 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 des raisons de simplicité et d’entretien facile, j’ai un fichier * .targets qui connaît chaque répertoire de ce type; tous mes projets Importer ce fichier.

3. Assurez-vous que votre stratégie de contrôle de version (création de branches, fusion, & locale; - > mappages de serveur) conserve les chemins relatifs entre vos projets & amp; vos chemins de référence constants.

EDIT

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

4) Assurez-vous que chaque référence d'assemblage dans chaque fichier de projet utilise le nom fort .Net complet et rien d'autre .

Mauvais:

<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 de ce dernier format:

• L'utilisation d'un chemin HintPath dans un environnement de développement collaboratif conduira inévitablement à des situations où & "Cela fonctionne pour moi &"; mais pas les autres. Surtout votre serveur de construction. L'omettre vous oblige à corriger les chemins de référence ou à la compilation.
• L'utilisation d'un nom faible invite à la possibilité d'un " DLL enfer. " Une fois que vous utilisez des noms forts, il est prudent de disposer de plusieurs versions du même assemblage dans vos chemins de référence, car l'éditeur de liens ne chargera que celles correspondant à chaque critère. De plus, si vous décidez de mettre à jour certains assemblys sur place (au lieu d’ajouter des copies), vous serez averti de toute modification récente au moment de la compilation au lieu de à chaque fois que les bogues commencent à arriver.

Answer 2

En ajoutant à ce que tout le monde dit, cela revient essentiellement à deux choses:

1. Assurez-vous que tous les développeurs ont les mêmes versions de bibliothèques externes
2. Assurez-vous 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 AdditionalReferencePath pour vous aider à résoudre le problème # 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 transmettre ReferencePath en ligne de commande. Pour résoudre le problème # 1, j'ai trouvé svn: externals utile (si vous utilisez SVN).

Mon expérience avec Maven est qu’il est excessif dans la plupart des cas.

Answer 3

J'ai généralement une structure de dossiers distincte sur le contrôle de code source pour les dépendances internes ou internes, et ces filders possèdent les assemblys en fonction du numéro de version ou de version, par exemple

.

public \ External \ libraries \ Nunit \ 2.6 \

ou

Public \ Internal \ libraries \ Logger \ 5.4.312 \

et à l'intérieur des solutions, tous les projets devant utiliser l'une des dépendances ne font qu'ajouter une référence à ces assemblys dans les dossiers internes ou externes publics.