Dépendances d'écrasement de MSBuild

Question

Ok, donc j'ai un problème un peu compliqué avec mon environnement de construction que j'essaie de gérer.

J'ai un fichier de solution qui contient plusieurs projets C# qui est construit par un script NAnt appelant MSBuild - en passant MSBuild le nom du fichier de solution et un chemin pour copier les binaires. C'est parce que je veux que mon environnement de compilation automatisé (CruiseControl.Net) crée un dossier nommé après la révision de chaque build - de cette façon, je peux facilement revenir aux binaires précédents pour une raison quelconque.

donc idealement J'ai une mise en page du dossier comme celui-ci

c:\build\nightly\rev1 
c:\build\nightly\rev2 
c:\build\nightly\rev3 
... 
c:\build\nightly\rev10 
etc. 

Le problème qui surgie est moi récemment ajouté la dernière version du conteneur Unité IoC à mon projet, vérifier directement sur dépôt SVN en ligne MS. Ce qui se passe, c'est que j'ai un projet Silverlight 3 qui fait référence à la version Silverlight d'Unity mais j'ai aussi d'autres projets (à savoir mon projet de test Unit) qui référencent la version standard (non-Silverlight) d'Unity.

Alors que MSBuild vide tout dans un seul dossier, la version Silverlight de l'assembly Unity remplace la version non-Silverlight car ils ont exactement le même nom de fichier d'assembly.

Ensuite, lorsque CruistControl exécute mes tests unitaires, ils échouent car ils ne disposent plus des dépendances appropriées (ils essaient de charger l'ensemble Unity spécifique à Silverlight qui, évidemment, ne fonctionne pas).

donc ce que je veux faire est:

• garder ma structure désirée répertoire de sortie (dossier de révision \)
• Je ne veux pas avoir à modifier manuellement chaque fichier proj je car ce est sujette aux erreurs lors de l'ajout de nouveaux projets à la solution

Idealy Je voudrais MSBuild tout mettre dans une structure de dossiers semblable à ceci:

nightly\revision1\project1 
nightly\revision1\project2 
nightly\revision1\project3 
... 
nightly\revision2\project1 
nightly\revision2\project2 
nightly\revision2\project3 
etc 

Je ne peux pas modifier le projet Unity pour lui donner un nom de fichier différent parce qu'il vient d'un autre dépôt SVN Je ne peux pas valider les modifications à. J'ai trouvé une question similaire postée ici et la solution suggérée était d'utiliser un fichier MSBuild "master" qui utilisait une tâche personnalisée pour extraire tous les noms de fichiers du projet hors de la solution puis passer en boucle sur chacun d'eux. J'ai essayé cela mais il ne les construit pas dans l'ordre de leurs dépendances, donc ça échoue pour mon projet.

Aide?

Answer 1

Tout d'abord, je voudrais toujours que le serveur de construction supprime l'ancienne copie de travail et en extrait une nouvelle copie pour éviter tout problème avec les artefacts périmés de la version précédente.

Ensuite, j'aurais nant ou msbuild construire les solutions comme avant avec les artefacts de chaque build allant vers leurs dossiers de sortie de travail locaux. Après cela, je déplacerais les artefacts de leurs chemins de travail vers leurs chemins de sortie, cela ne devrait pas nécessiter de creuser dans les fichiers du projet puisque vous pouvez simplement dire à msbuild/nant de copier working\project1\bin\release\**\*.* à artifacts\project1\.

Le script qui le fait devrait idéalement être stocké avec la source avec le fichier principal, par ex. build.nant ou build.proj au niveau supérieur du coffre.

Answer 2

Pour les bibliothèques tierces j'inclurais simplement le répertoire DLL dans votre référentiel. Rien de pire que d'écrire du code et d'avoir une dépendance tierce brise votre build à cause des changements de leur côté.

documenter simplement les versions des bibliothèques que vous utilisez et si vous devez les mettre à jour, vous aurez une meilleure idée de ce qui brise la construction avant de vérifier même dans.

Aussi, ne CC.Net gère automatiquement la fourniture de versions basées sur la révision? J'utilise TeamCity et conserve une copie des artefacts de chaque build.

Je recommande fortement de lire la série de blogs de JP Boodhoo Automating Builds with NAnt. Cela a été mon point de départ et j'ai fait beaucoup de changements à mon goût. Je recommande également fortement de vérifier les constructions de nombreux projets de sources ouvertes pour des exemples. J'ai beaucoup appris des builds de la pile Castle/Nhibernate/Rhino-Tools.