我们非常广泛地使用 MSBuild 作为我们持续集成过程的一部分，虽然它非常强大，我们几乎可以在其中完成所有构建、测试和部署（利用一些自定义任务） - 我们发现使用标签对其进行调试是一种痛苦，并且不能总是为我们提供足够的信息。
我发现：http://www.wintellect.com/CS/blogs/jrobbins/archive/2007/12/03/msbuild-debuggers.aspx http://www.wintellect.com/CS/blogs/jrobbins/archive/2007/12/03/msbuild-debuggers.aspx，但不幸的是该项目似乎已经从 Codeplex 中消失了。
有谁知道是否有类似的东西可用，或者是否有其他可以使用的方法/技术？
Thanks.
我用/v:diagnostic命令行开关。 MSBuild 会输出一些相当详细的输出。您还可以使用以下命令将详细输出吐出到日志文件而不是控制台/fl[n]命令行开关，然后使用/flp[n](filelogparameter) 开关来指定详细级别，例如，/flp:Verbosity=diagnostic;LogFile=latest_diagnostic.log
您必须从一开始就设计构建脚本，以便更轻松地进行故障排除。做这样的事情：
使每个目标尽可能细化，以便您可以单独调用每个目标。这有助于使调试过程更快。
确保您的任务继承自Microsoft.Build.Utilities.Task班级。它公开了一个具有太多日志记录功能的 Log 属性。我通常会谨慎使用LogMessage(MessageImportance,string,params object[])。我的调试消息的消息重要性为MessageImportance.Low因此它们仅在详细模式为诊断模式时出现。
Use System.Diagnostics.Trace.WriteLine用于输出级别太低而无法记录的消息。我用调试视图 http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx查看这些消息。
最后，尽量不要在 MSBuild 脚本本身中执行非常复杂的操作。 MSBuild 擅长管理依赖项、文件列表和运行任务。任何更复杂或更高级的任务都应该转移到用您选择的 .NET 语言编写的自定义任务中。这对于制作东西有额外的好处much更容易调试。当您在代码中找到逻辑后，您可以使用System.Diagnostics.Debugger.Launch()方法，该方法允许您将 MSBuild 附加到正在运行的 Visual Studio 实例（希望已加载自定义任务的实例）中的调试器。
祝你好运！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
