J'ai un fond de Java, donc je suis habitué à avoir Maven gérer tous les problèmes de téléchargement et de conservation des dépendances à jour. Mais dans l'environnement .NET, je n'ai pas encore trouvé de bon moyen de gérer toutes ces dépendances externes.
Le problème principal ici est que je produit des solutions de masse et ils ont tous tendance à dépendre de la même dll tiers. Mais je ne veux pas maintenir des copies séparées de chaque composant sous chaque solution. J'ai donc besoin d'une façon de relier toutes les solutions différentes au même ensemble de DLL.
J'ai réalisé qu'une solution pourrait être d'inclure les bibliothèques externes dans un «projet de bibliothèque» incluse dans toutes les solutions et laissez les autres projets les références à travers elle. (Ou assurez-vous simplement de faire référence à la DLL externe du même endroit pour tous les projets.)
Mais y a-t-il de meilleurs moyens de faire cela? (De préférence en utilisant une sorte de plug-in pour Visual Studio.)
J'ai regardé le Visual Studio Dépendency Manager et cela ressemble à un match parfait mais que quelqu'un a essayé Pour de vrai? J'ai aussi vu les ports .NET de Maven, mais malheureusement, je n'ai pas été trop impressionné par le statut de ceux-ci. (Mais s'il vous plaît, allez-y et recommandez-leur quiconque si vous pensez que je devrais leur donner un autre essai.)
Alors, quel serait le moyen le plus intelligent de s'attaquer à ce problème?
J'ai réalisé que je devais expliquer ce que je voulais dire avec lier au même ensemble de DLL .
Une des choses que j'essaie d'atteindre ici est d'éviter que les différentes solutions référencent différentes versions de chaque composant. Si je mettez à jour un composant à une nouvelle version, il devrait être mis à jour pour toutes les solutions lors de la prochaine version. Cela me forcerait à m'assurer que toutes les solutions sont à jour avec les derniers composants.
3 Réponses :
J'ai généralement une structure de dossiers distincte sur le contrôle source des dépendances extrénaires ou internes, et ces friders ont les assemblages en fonction de la construction ou du numéro de version, par exemple
Public \ External \ Bibliothèques \ Nunit \ 2.6 \
ou
Public \ Internal \ Bibliothèques \ Logger \ 5.4.312 \
et à l'intérieur des solutions Tous les projets qui doivent utiliser l'une des dépendances ajoute simplement une référence à ces assemblages dans les dossiers internes ou extrénaires publics.
Trouvez un endroit pour stocker les assemblages. Par exemple, je stocke les assemblages de noyau .NET comme: p>
> \ NetFX \ 2.0527 \ code> * li>
-
> \ NetFX \ 3.0 \ code> * li>
-
> \ NetFX \ 3.5 \ code> * li>
-
> \ NetFX \ Silverlight 2 \ code> * li>
-
> \ NetFX \ Silverlight 3 \ code> * li>
ul> li>
-
Utilisez la propriété de référencePathe dans Msbuild (ou DoubleReferencePath dans la construction de l'équipe) pour pointer vos projets sur les chemins appropriés. Pour la simplicité et la maintenance facile, j'ai 1 * .Targets dossier qui connaît tout ce type de tel répertoire; Tous mes projets importent ce fichier. p> li>
- Assurez-vous que votre stratégie de contrôle de version (ramification, fusions, locales serveur) maintient les chemins relatifs entre vos projets et vos chemins de référence constants. li>
EDIT P>
En réponse à la mise à jour de la question, laissez-moi ajouter une étape de plus: p>
4) Assurez-vous que chaque référence de montage dans chaque fichier de projet utilise tout le fichier de projet. Nom fort et rien d'autre em>. p> Bad: P>
<Reference Include="Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" />
- L'utilisation d'un hintpath dans un environnement de développement collaboratif conduira inévitablement à des situations où "cela fonctionne pour moi" mais pas d'autres. Surtout votre serveur de construction. Omission que cela vous oblige à obtenir vos chemins de référence corrects ou cela ne compilera pas. Li>
- L'utilisation d'un nom faible invite la possibilité de "DLL HELL". Une fois que vous utilisez des noms forts, il est prudent d'avoir plusieurs versions du même assemblage dans vos chemins de référence car la lieur ne chargera que ceux qui correspondent à tous les critères. En outre, si vous décidez de mettre à jour des assemblages en place (au lieu d'ajouter des copies), vous serez notifié de tout changement de rupture au moment de la compilation au lieu de chaque fois que les bogues commencent à arriver. Em> li>
ul> ol>
Oui, bien sûr, Msbuild. Je suppose que ce n'était qu'une question de temps avant que je doive apprendre à l'utiliser ...;) Cela ressemble à une bonne solution générale, mais je suis toujours ouvert pour d'autres suggestions.
Merci, cela aide, bien que l'une de mes questions soit obligée d'utiliser des noms faibles pour certaines dépendances. Par exemple. MEF.CODEPLEX.COM/THRead/view.aspx?TridAf=57524 (Je ne suis pas tout à fait prêt pour le .NET 4.0 Beta encore.) Donc, c'est le cœur de mon problème, mais maintenant, il est probablement satisfaisable. J'ai juste besoin d'écrire un script qui trouve et supprime toutes les assemblées locales dans une solution en veillant à ce qu'il ne puisse que les assemblages de référence indiqués par la propriété de référencePathe.
Oui, si le projet est assez important pour avoir plusieurs développeurs et plusieurs dépendances externes, être capable de la construire avec Msbuild ou MS Team Buily est bien essentiel. Une note latérale sur l'utilisation de noms forts: j'ai vu des gens avoir des ennuis parce qu'ils utilisaient faiblement nommé
@DanielPryden: Je suis d'accord avec votre déclaration sur l'utilisation de références de projet et SVN: externes au lieu de références DLL. Est-ce une "meilleure pratique" pour .NET, et si oui, il est publié quelque part? Nous utilisons Jenkins en ce moment et essayons de passer des artefacts du travail en aval.
Ajout de ce que tout le monde dit, cela revient fondamentalement à deux choses:
Comme Richard Berg souligne, vous pouvez utiliser RefreefPathePath et / ou ShareDrefereferPath pour vous aider à résoudre le numéro 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 transmettre de référence à la ligne de commande sur la ligne de commande. Pour résoudre le n ° 1, j'ai trouvé SVN: externals être utile (si vous utilisez svn).
Mon expérience avec Maven est que c'est bien survenir à la plupart des fins.
Oui, en fait, c'est presque ce que je fais en ce moment. J'utilise SVN: externes pour inclure d'autres choses communes pour toutes les solutions. C'est probablement une grande solution dans la plupart des cas et constituerait également mes retombées pour les dépendances. Mais toujours, je veux un moyen plus rapide / plus facile de gérer les dépendances, de préférence sans avoir à les stocker dans SVN du tout. Je viens d'essayer le gestionnaire de dépendance Visual Studio et cela me donne la vitesse que je recherche lors de la gestion des dépendances (faites glisser-déposer à partir d'un référentiel et un seul clic pour mettre à jour pour la dernière fois).
Quel type d'outil de contrôle source utilisez-vous?
Svn mais ce n'est pas une exigence pour une bonne solution. Je peux facilement changer d'environnement.