Référencement d'assemblages en dehors du GAC sans correction du chemin

Question

Je suis actuellement en train de rechercher les meilleures pratiques de développement et de déploiement pour notre équipe. Nous avons une charge de code similaire que nous allons commencer à importer dans une bibliothèque d'assemblages partagés pour une utilisation dans notre suite d'applications (web & win). Je commence à avoir une idée claire de l'endroit où je pense que nous devrions nous diriger. J'aurai sans doute d'autres questions à mesure que ce processus d'affinage progressera.

Je suis attiré par l'élégance de la structure décrite dans W Craig Trader's répondre à this question. Nous utilisons TFS plutôt que SVN mais l'approche s'applique tout aussi bien. En utilisant cette approche, chaque dev aura un espace de travail local contenant le dernier assemblage partagé pour chaque version majeure. Chacun de ces assemblys sera exactement ceux qui seront déployés dans le GAC de l'hôte cible.

Chaque membre de l'équipe de développement est libre de mettre en forme sa machine dans la mesure où il se sent le plus à l'aise pour que le répertoire contenant les assemblages à lier puisse facilement passer de dev à dev. Nous ne voulons pas stocker les assemblages dans le GAC des machines des développeurs. Et je ne veux pas que chaque développeur doive mettre à jour les références chaque fois qu'il vérifie un projet.

Ma question est la suivante: existe-t-il un moyen de configurer un dossier pour qu'il agisse comme un magasin d'assemblage à l'échelle du système? la GAC? Ou existe-t-il un moyen de configurer VS2008 pour rechercher des assemblages dans un emplacement particulier? Dans l'avenir, nous allons configurer les builds automatisés/CI, auquel cas nous pouvons réparer ces choses, mais dans l'intervalle les builds auront lieu sur la machine d'un développeur individuel. Mais même avec des builds basés sur le serveur, chaque développeur voudra référencer l'assemblage correct pour les builds intellisense et test.

Toutes pensées ou suggestions sont les bienvenues.

Merci, Dan

Après discussion interne est semble que nous pouvons régler sur un emplacement fixe sur la machine de chaque Dev. Cela ne tient toujours pas bien d'un espace de travail personnel p-o-v mais c'est l'approche la plus sûre.

L'alternative est d'écrire un écouteur d'événement TFS côté client qui peut augmenter un fichier de projet lors de l'extraction et l'assainir lors de l'archivage. Mais je ne suis pas sûr à quel point cela serait sûr.

Cheers, Dan

Answer 1

à mon travail précédent tous les développeurs avaient un R: \ lecteur qui contient tous les ensembles partagés. Avec un script, les assemblys sur le disque ont été mis à jour en les copiant à partir d'un partage réseau.

Answer 2

NuGet permet de résoudre ce problème. Construisez votre code partagé en tant que paquets nuget, puis vous pouvez utiliser local feeds stocké sur un lecteur réseau ou un serveur partagé pour héberger vos paquets nuget. Je viens de voir que Teamcity 7 a même un support natif pour l'hébergement de flux de nuget maintenant. L'avantage de ceci est qu'il est facile de partager des bibliothèques sans fixer des emplacements (par exemple, peu importe comment un développeur ou un serveur de construction donné a ses répertoires organisés), et vous pouvez compter sur des versions spécifiques ainsi que rester facilement sur la dernière version. Les paquets Nuget peuvent aussi faire autre chose que fournir de simples références DLL: par exemple, il est possible de distribuer des bibliothèques javascript ou des images ou tout autre contenu.Si vous créez plusieurs applications Web qui partagent toutes la même configuration commune (styles, formulaires, connexions, etc.), vous pouvez empaqueter les fichiers/bibliothèques/etc requis dans un paquet nuget, puis ajouter simplement la référence au package.