Nous utilisons Msbuild assez largement dans le cadre de notre processus d'intégration continue et, tandis que c'est incroyablement puissant et que nous puissions faire pratiquement toutes nos constructions de construction, de test et de déploiement à l'intérieur (en utilisant des tâches personnalisées) - nous avons constaté que le débogage Il utilise des balises est une douleur et ne peut pas toujours nous fournir suffisamment d'informations.
J'ai trouvé: http : //www.wintellect.com/cs/blogs/jrobbins/archive/2007/12/03/msbuild-debuggers.aspx , mais malheureusement, le projet semble avoir disparu de Codépex.
Quelqu'un a-t-il une idée s'il y a quelque chose de similaire à celui-ci disponible ou s'il y a un autre moyen / technique pouvant être utilisé?
Merci.
5 Réponses :
J'utilise le commutateur de ligne Vous devez concevoir vos scripts de construction du début pour effectuer un dépannage plus facile. Faire des choses comme:
rendez chaque cible aussi granuleuse que possible, de sorte que vous pouvez appeler chaque cible individuellement. Cela aide à rendre le processus de débogage beaucoup plus rapide.
Assurez-vous que vos tâches héritent de la catégorie Utiliser Enfin, essayez de ne pas faire des choses vraiment compliquées dans le script Msbuild lui-même. Msbuild excelle à la gestion des dépendances, des listes de fichiers et des tâches d'exécution. Tout ce qui est plus compliqué ou avancé doit être déplacé vers des tâches personnalisées écrites dans votre langue de choix .NET. Cela a l'avantage supplémentaire de faire des choses beaucoup plus faciles à déboguer. Lorsque vous avez votre logique dans le code, vous pouvez utiliser bonne chance! / v: diagnostique . Msbuild crache une jolie sortie verbeuse. Vous pouvez également cracher la sortie Verbose à un fichier journal au lieu de la console, à l'aide du commutateur de ligne / fl] , puis utilisez le / sol [n] (Filelogparamètre) Switch Pour spécifier le niveau de verbosité, par exemple, /flp:verbosity=diagnostic ;logfile=Latest_Diagnostic.log
microsoft.build.uties.task . Il expose une propriété journale qui a trop de fonctions de journalisation. Je vous trompe généralement sur le côté de la prudence, utilisez le LogMessage (MessageImportance, String, Objet Params []) . Mes messages de débogage reçoivent un message d'importance de MessageImportance.low afin qu'ils n'apparaissent que lorsque le mode de verbosité est diagnostique.
system.diagnostics.trace.writeline pour la sortie de messages qui sont trop bas pour se connecter. J'utilise DebugView pour examiner ces messages.
system.diagnostics.debugger.launch () méthode, ce qui vous permettra de joindre Msbuild au débogueur dans une instance d'exécution de Visual Studio (espérons-le. celui qui a votre tâche personnalisée déjà chargée).
joli verbeux? C'est un euphémisme, j'ai eu des lignes de sortie de 45k de ma construction avec ce drapeau! Bonne réponse.
Vous pouvez également consulter l'excellente application commerciale (avec essai de 14 jours) Sidekick Msbuild à Attrce Corp pour déboguer votre script Msbuild.
Eh bien, si vous utilisez des tâches personnalisées, vous pouvez utiliser cette approche: Comment: déboguer une tâche MSBuild personnalisée à l'aide de Visual Studio
Vous pouvez passer à travers C'est un simple changement de registre, puis un interrupteur Voir ici pour une procédure complète: http://blogs.msdn.com/b/visualstudio/archive/2010/07/06/debugging-msbuild-script-with-visual-studio.aspx msbuild scripts dans Visual Studio si vous utilisez msbuild 4.0 ou supérieur.
/ débogage lors de l'exécution msbuild .