visual studio.net dll problèmes de référence

Question

Nous avons plusieurs projets, bibliothèques et solutions C# (quelques applications asp.net, quelques bibliothèques de classes, des applications Windows comme Windows Services et Winform Apps, etc.) dont la plupart dépendent de chaque D'autres éditent des DLL. Certains de nos projets sont regroupés en solutions et utilisent la dépendance du projet. Mais certains projets ne le sont pas. Nous utilisons (malheureusement) VSS pour gérer les sources. Lorsque je référence des assemblages à un projet, je vois parfois des fichiers rafraîchis stockés dans vss mais la DLL réelle ne vient jamais lorsque vous obtenez la dernière version, parfois seulement les assemblys mais pas les vss gérés, parfois seulement les assemblys et ils semblent être gérés par vss. Comme vous pouvez le deviner, c'est un cauchemar de gérer ces fichiers pour nous, surtout lors de la publication des applications web. nous ne sommes jamais sûrs que les dernières versions des DLL de la bibliothèque soient publiées. Pouvez-vous conseiller les meilleures pratiques concernant la gestion de cette complexité? Tous les articles sont les bienvenus aussi. Devrions-nous conserver toutes les bibliothèques dans un dossier réseau et utiliser des fichiers d'actualisation? Donc, chaque développeur de l'équipe doit copier son fichier de sortie sur ce partage réseau?

Merci, Umut

Answer 1

Ce que je fais pour résoudre ce problème est de déposer une copie des DLL référencés dans le répertoire bin de mes applications web, et les inclure dans le cadre du projet, enregistré dans la source sûre.

De cette façon, si la DLL est toujours mis à jour, il est aussi simple que Check Out - Ecraser - Arrivée et tous les membres de l'équipe peuvent avoir le dernier fichier.

Et, en outre, il rend le déploiement facile, car les fichiers sont inclus lors d'une publication. Réglez simplement le type de construction au contenu.

Answer 2

La plus simple et la plus manuelle serait d'avoir une sorte de documents quelque part qui définit votre application Web et indique que ses dependecies sont, la version d'entre eux, et leur emplacement dans la source de sécurité. Ajoutez cela dans le cadre d'un script de construction.

Une approche plus difficile et moins manuelle consisterait à mettre en œuvre une certaine forme d'automatisation de la construction. Je suggère de jeter un coup d'oeil à MSBuild (http://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx), qui utilise des fichiers XML comme une sorte de langage de script. Téléchargez également le package Tâches de communauté (http://msbuildtasks.tigris.org/). Avec ces deux outils, vous devriez être capable de générer un fichier MSBuild qui récupère vos différentes solutions de sourcesafe puis les compile (notez que vous pouvez appeler un fichier MSBuild depuis un fichier MSBuild.) Notez également qu'un fichier Visual Studio Solution est un fichier MSBuild - vous pouvez avoir votre script MSBuild juste lancer la construction que vos développeurs ont créé dans Visual Studio). Une fois cela fait, vous pouvez ensuite déployer le résultat où vous voulez.