version control - MSBuild-Utilisez le fichier.csproj ou lancez le vôtre?




version-control continuous-integration (5)

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

Cela étant dit, j'essaie de mettre en place un environnement CC.NET pour me renseigner, mais j'ai de la difficulté à trouver les informations dont j'ai besoin pour configurer la partie automatisée.

Si je comprends bien, en C # le fichier .csproj produit par VS 2005 et forward est un fichier MSBuild valide. Pour ainsi dire, j'ai pu intégrer la tâche MSBuild dans CC.NET en utilisant le fichier .csproj, mais j'ai quelques problèmes avec ceci:

  1. Il se passe beaucoup de choses ici dont je ne suis pas sûr que j'ai vraiment besoin dans un environnement de construction automatisé.
  2. Je n'ai pas créé ce fichier. Je ne comprends pas, et ça me fait peur. ( Programmation par coïncidence )
  3. La plupart de ce qui se passe semble être extrait par $(MSBuildToolsPath)\Microsoft.CSharp.targets
  4. À la suite de 1, 2 et 3, modifier le fichier pour inclure quelque chose comme MbUnit semble compliqué et plus difficile que nécessaire. Ma seule vraie option est de l'inclure dans la section AfterBuild , qui me semble être un hack.

Donc, quelques questions pour les gens de CC.NET, les gens de MSBuild, et les gens de MbUnit.

  1. Lorsque vous utilisez MSBuild, est-il conseillé d'utiliser le fichier .cspro généré par 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? Ma recherche semble suggérer qu'ils appartiennent au fichier MSBuild. Si c'est le cas, puis-je créer un nouveau fichier .proj MSBuild et le vérifier dans CVS en plus du fichier .csproj? Ou la tâche MbUnit fait-elle partie de mon fichier .csproj?
  3. Similaire à la question 2. Si j'ajoute les tests MbUnit au fichier MSBuild et que je finis d'utiliser le fichier .csproj, est-ce que Target Name="AfterBuild" vraiment la section pour ajouter cette information? Ne devrait-il pas y avoir une section Target Name="Test" ? L'utilisation du fichier .cspro généré par VS semble empêcher la deuxième option.

Je sais qu'il y en a beaucoup, mais la plupart de ce que j'ai pu trouver en ligne suppose un certain niveau de familiarité avec ces sujets que je n'ai tout simplement pas - à moins que je me trompe, la courbe d'apprentissage pour ce genre de choses 'T une courbe du tout, c'est une fonction d'étape. :)

Edit 1: J'ai mis à jour le texte pour être un peu plus concis et pour répondre à quelques questions persistantes que j'ai eu avec les réponses.


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

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

Cette séparation facilite l'ajout de vos propres tâches pré et post (tests unitaires, tests de fumée, scripts SQL, fxcop / autres analyses statiques, etc.) et vous ne casserez pas votre environnement de travail. Cela signifie également que vous pouvez faire vos cibles personnalisées dans tout ce que vous souhaitez (msbuild / ant, etc.) Jetez un coup d'oeil comme MSBuildContrib sur codeplex pour plus de qualité.

Vous n'avez pas besoin de stuido visuel sur votre serveur de construction (vous avez des projets de déploiement, à moins que cela n'ait été changé depuis la dernière fois)


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

Quant à votre question de construire votre propre fichier csproj ou d'utiliser celui créé par VS2005, je vous suggère un moyen terme: créer votre propre modèle de projet , qui répond à vos besoins et laisser VS s'occuper du reste.


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 ça:

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

Notez que msbuild peut aussi construire .sln (fichier de solution) sans aucun changement, ce qui est généralement plus facile que d'avoir un tas de fichiers csproj ...


J'utilise à la fois NAnt et MSBuild. NAnt a été mis à jour avec NAntContrib pour que je puisse avoir msbuild . Je suis peut-être une installation temporaire mais jusqu'à présent, je n'ai pas eu de problèmes majeurs. Cela dit, je ne crée pas non plus un nouveau fichier csproj car j'utilise le même csproj / sln que j'utilise dans VS2008. La construction de projets avec msbuild a grandement simplifié les scripts NAnt hérités (nous avons utilisé la tâche csc ).

Remarques:

  1. Si vous utilisez Windows Workflow Foundation dans vos projets, vous aurez de grandes difficultés à construire un tel projet sans msbuild.
  2. N'installez pas VS.NET sur votre machine de build. Vous pouvez utiliser Wix pour créer des msi d'installation.
  3. @Franci Penov: Les tests unitaires en cours d'exécution DEVRAIENT faire partie de chaque build. Voulez-vous vraiment attendre jusqu'à demain pour trouver un bug? Il y a une remarque: les tests unitaires devraient être très rapides.

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

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

À des fins d'apprentissage, vous voudrez peut-être enregistrer la construction d'un .csproj et passer en revue pour avoir une idée de ce qui se passe. MSBuild est un peu plus déclaratif que nant, alors prenez votre temps et expérimentez un peu.

Enfin, je voudrais envelopper vos fichiers .sln ou .csproj dans un projet de script de construction continue avec des tâches msbuild pour construire vos projets et exécuter vos tests unitaires ensemble. De cette façon, les développeurs n'ont pas besoin d'exécuter le test unitaire à chaque fois qu'ils le construisent - mais chaque fois qu'ils intègrent leur code, les tests unitaires sont exécutés. Et oui, assurez-vous qu'ils courent vite! Tout ce qui prend plus d'une seconde doit être exécuté au cours d'une compilation planifiée (nocturne?) À la place. Probablement ils sont moins de tests unitaires et plus de tests d'intégration écrits avec un cadre de test unitaire s'ils prennent plus d'une seconde.

Edit: Quelques informations supplémentaires que j'ai trouvé utiles - l'utilisation de MSBuild 3.5 vous permettra d'obtenir la sortie cible d'un fichier .sln, alors que cette information n'est pas retournée dans MSBuild 2.0 (bien que je pense que cela devrait fonctionner pour .csproj fichiers dans les deux versions). Vous pouvez utiliser la sortie (vos fichiers générés) comme entrées dans votre infrastructure de test.





mbunit