Utilisation de subversion et de Nant pour la construction. J'ai un projet principal qui dépend de plusieurs sous-projets. Les sous-projets existent en tant que projets séparés à l'intérieur de subversion.Nant: création de projets à l'aide de svn-externals
Ma question est: Est-ce que le script de construction nant dans le projet principal doit construire tous les sous-projets référencés et lui-même? Ou est-ce que les sous-projets savent comment se construire et j'appelle d'une manière ou d'une autre les fichiers de construction du sous-projet à partir du fichier de construction principal et assembler en quelque sorte tous les résultats dans la sortie de construction des projets principaux?
J'ai actuellement le fichier de construction de mainproject construire tous les sous-projets. C'est-à-dire que j'ai des cibles nant pour chaque sous-projet dans le fichier de construction. Cependant, cela semble créer un couplage étroit entre le fichier de construction principal et les sous-projets. Ce serait bien si je pouvais juste dire «les sous-projets savent comment se construire» et leur demander de se construire à partir du projet principal et d'assembler les résultats.
Pour référence, mon dépôt ressemble à:
/Repo
/MainProject
/trunk
/doc <-- documentation
/lib <-- binary-only DLLs (usually 3rd party)
/src <-- source code for MainProject
/svn-externals <-- hold references to other projects in repository
...
/ClassLib1
/trunk
/doc
/lib
/src
/svn-externals
...
/ClassLib2
/trunk
/doc
/lib
/src
/svn-externals
...
/ClassLibCommon
/trunk
/doc
/lib
/src
/svn-externals
Je tire dans les sous-projets en utilisant la subversion propriété svn-externals. Donc, ma copie de travail est comme ceci:
/MainProject
/build
/doc
/lib
/src
/MainProject
/svn-externals
/ClassLib1 <-- svn external to svn://xyz/repo/ClassLib1/trunk
/doc
/lib
/src
/svn-externals
/ClassLibCommon <- svn external to svn://xyz/repo/ClassLibCommon/trunk
...
/ClassLib2 <-- svn external to svn://xyz/repo/ClassLib2/trunk
/doc
/lib
/src
/svn-externals
/ClassLibCommon <- svn external to svn://xyz/repo/ClassLibCommon/trunk
...
Les projets de bibliothèque sont utilisés par d'autres projets "principaux". Ce sont des références de projet. Deux choses: 1. Les bibliothèques changent fréquemment. 2. Je pensais que la sagesse conventionnelle est de ne pas stocker les binaires pour les choses dont vous avez le code source. – User
Cela dépend. Pour moi, ne pas référencer un projet dans plus d'une solution sur les manèges que. Je considère que les bibliothèques partagées ne font pas partie du projet principal. Donc, tout comme je mets mes DLL de rapport Crystal dans svn, j'y mets aussi mes DLL Framework internes. De plus, les références DLL vous donnent plus de contrôle sur la version de la bibliothèque que vous utilisez avec chaque projet. Bien sûr, vous pouvez faire ce qui précède et ne pas mettre les binaires dans svn. Mettez-les sur un partage réseau. – PilotBob
"Pour moi, ne pas référencer un projet dans plus d'une solution remplace cela" Je ne suis pas sûr de comprendre cela.Juste pour clarifier, quand j'utilise le terme «projet», je veux dire dans le sens général, pas dans le sens du studio visuel. Donc à mon avis, par définition, un «projet» de bibliothèque de classes (en fait, c'est sa propre solution) est destiné à être utilisé dans plus d'une solution. – User