MSBuild & # 8212; Utilisez le fichier .csproj ou roulez le vôtre?

Question

OK, je concède volontiers que je suis un débutant en matière d'intégration continue.

Cela étant dit, j'essaie de configurer un environnement CC.NET pour me renseigner, mais je ne parviens pas à trouver les informations dont j'ai besoin pour configurer la partie de construction automatisée.

Si je comprends bien, en C #, le fichier .csproj produit par VS 2005 et avant est un fichier MSBuild valide. En particulier, j’ai pu intégrer la tâche MSBuild à CC.NET à l’aide du fichier .csproj, mais j’ai quelques problèmes à résoudre:

1. Il se passe beaucoup de choses ici dont je ne suis pas sûr d'avoir réellement besoin dans un environnement de construction automatisé.
2. Je n'ai pas créé ce fichier. Je ne le comprends pas et cela me fait peur. ( Programmation par coïncidence )
3. La plupart de ce qui se passe semble être résumée via $ (MSBuildToolsPath) \ Microsoft.CSharp.targets
4. En conséquence de 1, 2 et 3, la modification du fichier pour y inclure quelque chose comme MbUnit semble compliquée et plus difficile qu'il ne le faut. Ma seule véritable option est de l'inclure dans la section AfterBuild , ce qui me semble un peu comme un piratage.

Quelques questions pour les collaborateurs de CC.NET, de MSBuild et de MbUnit.

1. Lorsque vous utilisez MSBuild, est-il conseillé d'utiliser le fichier .csproj généré par le VS en tant que fichier de construction? Ou devrais-je créer le mien?
2. Les tests MbUnit doivent-ils faire partie du fichier MSBuild ou du fichier CC.NET? Mes recherches semblent suggérer qu'ils appartiennent au fichier MSBuild. Si tel est le cas, est-ce que je crée un nouveau fichier .proj MSBuild et le vérifie dans CVS en plus du fichier .csproj? Ou la tâche MbUnit devient-elle une partie de mon fichier .csproj?
3. Semblable à la question 2. Si j'ajoute les tests MbUnit au fichier MSBuild et finis par utiliser le fichier .csproj, le Target Name = "AfterBuild & " est-il vraiment la section permettant d'ajouter ces informations ? Ne devrait-il pas y avoir de section Target Name = " Test & ? L’utilisation du fichier .csproj généré par le VS semble empêcher la deuxième option.

Je sais qu’il ya beaucoup de choses là-bas, mais la plupart de ce que j’ai pu trouver en ligne suppose un certain niveau de connaissance de ces sujets que je n’ai tout simplement pas - à moins que je ne me trompe, la courbe d’apprentissage pour ce genre de choses n'est pas une courbe du tout, c'est une fonction de pas. :)

Modifier 1: le texte a été mis à jour pour être un peu plus concis et pour répondre à certaines questions en suspens que j'ai eues avec les réponses.

Answer 1

Je recommanderais l’utilisation des fichiers .csproj générés. En fait, pour la production, je pense que l’utilisation des fichiers .sln générés est une bonne idée. J'ai constaté que vous gagneriez en utilisant les mêmes fichiers de solution que les développeurs.

Sachez que les fichiers .sln ne sont pas des fichiers de projet msbuild valides - ils sont transformés en projets msbuild par msbuild lui-même lorsqu'ils sont utilisés en tant qu'entrées. Tricky!

À des fins d’apprentissage, vous voudrez peut-être vous connecter à la construction d’un fichier .csproj et vous y guider pour avoir une idée de ce qui se passe. Cependant, MSBuild est un peu plus déclaratif que nant, prenez donc votre temps et expérimentez un peu.

Enfin, je voudrais emballer vos fichiers .sln ou .csproj dans un projet de script de construction continu avec des tâches msbuild pour construire vos projets et exécuter vos tests unitaires ensemble. Ainsi, les développeurs n'ont pas à exécuter le test unitaire à chaque fois qu'ils construisent, mais chaque fois qu'ils intègrent leur code, les tests unitaires seront exécutés. Et oui, assurez-vous qu'ils courent vite! Tout ce qui prend plus d'une seconde devrait être exécuté lors d'une construction planifiée (chaque nuit?). Ils sont probablement moins de tests unitaires et plus de tests d'intégration écrits avec un framework de tests unitaires s'ils prennent plus d'une seconde.

Modifier: Certaines informations complémentaires que j'ai trouvées utiles: l'utilisation de MSBuild 3.5 vous permet d'obtenir le résultat cible à partir d'un fichier .sln, mais ces informations ne sont pas renvoyées dans MSBuild 2.0. (Bien que je pense que cela devrait fonctionner pour les fichiers .csproj dans les deux versions). Vous pouvez utiliser la sortie (vos fichiers générés) comme entrées dans votre framework de test unitaire.

Answer 2

Laissez le fichier csproj bien seul (comme vous dites, vous ne le comprenez pas).

Créez votre propre fichier msbuild proj et appelez csproj (ou sln) à partir de votre fichier de construction principal via la tâche msbuild. Dites à votre serveur CI de construire votre fichier de construction.

Cette séparation facilite l’ajout de vos propres tâches préalables et ultérieures (tests unitaires, scripts SQL de test de la fumée, analyse statique fxcop / autre, etc.) et vous ne risquez pas de casser votre environnement de travail. Cela signifie également que vous pouvez créer vos cibles personnalisées dans tout ce que vous souhaitez (msbuild / ant, etc.). Recherchez MSBuildContrib sur codeplex pour davantage de bonté.

Vous n'avez pas besoin de Visual Stuido sur votre serveur de build (sauf si vous avez des projets de déploiement, à moins que cela ne soit également modifié depuis mon dernier regard)

Answer 3

Créez votre propre fichier de projet (tout ce qui se termine par * proj est considéré comme un fichier de projet par MSBuild) et appelez votre build à partir de là. Comme ceci:

<MSBuild Projects="MySolution.sln" Targets="Clean; Rebuild" Properties="Configuration=$(BuildMode);">

Notez que msbuild peut également créer un fichier .sln (fichier solution) sans aucune modification, ce qui est généralement plus facile que de disposer de plusieurs fichiers csproj ...

Answer 4

J'utilise NAnt et MSBuild. NAnt a été mis à niveau avec NAntContrib afin que je reçoive msbuild taks. Je suis peut-être une configuration temporaire, mais je n’ai pas encore rencontré de problèmes majeurs. Cela dit, je ne crée pas non plus de nouveau fichier csproj car j’utilise le même csproj / sln que celui que j’utilise dans VS2008. La construction de projets avec msbuild a considérablement simplifié les scripts NAnt hérités (nous avons utilisé csc tâche).

Notes:

1. Si vous utilisez Windows Workflow Fondation dans vos projets vous allez avoir de grandes difficultés à construire une telle projet sans msbuild.
2. N'installez pas VS.NET sur votre machine de construction. Vous pouvez utiliser Wix pour créer un msi d'installation.
3. @Fanci Penov: Les tests unitaires en cours DEVRAIENT faire partie de chaque construction. Voulez-vous vraiment attendre jusqu'à demain pour trouver un bug? Remarque: les tests unitaires doivent être très rapides.

Answer 5

Personnellement, je pense que le fichier .csproj convient. Il n'y a pas grand chose à faire là-dedans que vous n'auriez pas à ajouter vous-même si vous lancez votre propre projet MSBuild.

Cependant, quelle que soit la route que vous décidiez d’aller, je vous recommanderais néanmoins de ne pas ajouter la MbUnit à votre étape de construction, mais de l’ajouter en tant qu’étape distincte dans CC.Net. Les tests unitaires en cours doivent faire partie du cycle quotidien de CI. cependant, cela ne devrait pas faire partie de chaque build.

Answer 6

OK, il y a peu de choses à surveiller. Le format csproj est passé de VS2005 à VS2008. De même, si vous utilisez MSBuild, n'oubliez pas que vous ne pourrez pas créer de fichiers .vdproj (setup); pour cela, vous avez besoin de devenv (l'exécutable du VS). Cela dit, vous pouvez toujours créer une tâche MSBuild qui appelle devenv et la construit pour vous.

En ce qui concerne votre question de savoir si vous souhaitez créer votre propre fichier csproj ou utiliser celui créé par VS2005, je suggérerais une voie intermédiaire: créez votre propre modèle de projet , qui répond à vos besoins et permet à VS de s'occuper du reste.

Answer 7

Vous pouvez utiliser .csproj comme entrée pour msbuild. Vous pouvez ajouter manuellement des tâches pour cela dans csproj qui seront ignorées lors de la validation à partir de VS. Mais si vous voulez faire des choses non triviales, il est préférable de créer des scripts séparés de msbuild. Et ils peuvent être référencés à partir de fichiers csproj. Avez-vous jeté un coup d'œil à MS Build Server qui fait partie de TFS? Il s'intègre au SourceControl de TFS et pourrait être utilisé pour le CI. Ses fichiers de projet sont des scripts msbuild.

  

Si j'ai utilisé nAnt, faut-il que VS soit installé sur le serveur?   Voulez-vous dire 'MSBuild'? Non, ce n'est pas nécessairement d'installer VS pour utiliser msbuild avec des fichiers csproj.