CCNET 构建报告中的异常行号混乱

发布于 2024-07-11 06:53:57 字数 169 浏览 10 评论 0原文

我们有一个集成服务器 (CruiseControl.NET) 来构建和验证几个 .NET 3.5 库。 当某些集成代码失败时,异常会被记录并显示在自定义报告中。

然而,异常消息报告的行号是混乱的 - 通常少于引发异常的位置下方的 50 / 100 行。

知道什么会导致这种情况吗?

We are having an integration server (CruiseControl.NET) building and validating a couple of .NET 3.5 libraries. When some integration code fails, the exception is logged and appears in a custom report.

Yet, the line numbers reported by the exception messages are messed-up - usually short from 50 / 100 lines below the place where the exception has been thrown.

Any idea what could cause such a situation?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

白鸥掠海 2024-07-18 06:53:57

您的构建过程是否在源代码中插入任何标头? 如果是这样,那么您可能会看到工作站上的行号与构建服务器上的行号之间存在偏移。

或者,您可能已更改构建过程以不再创建 PDB 文件,从而为新构建提供旧的行号。

不幸的是,由于 CCNet 配置是根据您的情况量身定制的,因此在没有更多信息的情况下很难进行诊断。 我建议将构建计算机磁盘上的源代码与工作站上的源代码进行比较,并查看报告的行号对于服务器的文件副本是否准确。

您还可以尝试强制进行干净的源签出并删除任何延迟的构建输出。

Does your build process insert any headers in the source code? If so, then you might see an offset between line numbers on your workstation and those on the build server.

Alternatively, you might have changed your build process to no longer create PDB files, giving you old line numbers for newer builds.

Unfortunately, because CCNet configuration is so tailored to your situation, it's hard to diagnose without more information. I would recommend comparing the source code on the build machine's disk with that on your workstation and seeing whether the reported line numbers are accurate for the server's copy of the files.

You might also try forcing a clean source checkout and delete any lingering build output.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文