我们有一个用C＃.NET编写的应用程序，目前在生产环境中使用。显然使用了发布版本。
不幸的是，有时应用程序在某些条件下行为不端，我们无法弄清楚原因。我们无法在内部重现这个问题。是的，更多的追踪会有所帮助，但通常是在您意识到应该实施更多追踪之后。
使用常规，逐行，Visual Studio Attach-to-Process类型调试来调试该安装的最佳方法是什么。是否在客户机器上安装VS的快速版本并用调试版本替换dll？只发送PDB和特定的源文件是否足够？有没有更好的办法？最终目标是使用类似环境的开发来调试问题。
答案 0 :(得分：7)
远程调试是一个很好的功能，但它很少在生产环境中使用，因为它需要很难实现的域（您自己和客户）之间的双向信任（两家公司的管理员都会强烈反对这个想法） ）
请参阅Remote Debugging Across Domains
但是，在您的应用程序中发送PDB文件会有所帮助。您可以要求您的客户使用Clr Debugger（DbgCLR.exe）与VS Debugger相比它有一些限制，但它仍然是一个可以完成工作的调试器，它是.NET SDK的一部分。 如果无法使用Clr Debugger调试问题，客户可以尝试在其生产环境中安装VS的试用版，并为您提供远程桌面连接（如果管理员允许您这样做）。我认为90天的试用期足以解决问题
您还可以尝试构建一个类似于客户的测试环境 - 限制（或增加）CPU数量，内存等，以尽可能匹配物理条件。如果您认为某些其他第三方软件或不存在的注册表记录会影响您的程序，请让您的客户创建其Windows的虚拟映像。
然而，我的经验是，由于多个用户的并发访问（死锁，竞争条件，First Wins / Last Wins场景中的逻辑错误行为），因此在50％的.NET中出现“不可重现”的错误。在大多数情况下，即使您在客户计算机上安装VS，也无法调试这些错误（如果您在非高峰时间运行此操作），因为您需要在不同的计算机上同时运行至少2个客户。
因此，在寻找为客户提供调试的选项时，请继续努力改进跟踪和监控功能。跟踪和性能计数器通常是您在生产环境中唯一的朋友。
答案 1 :(得分：2)
首先，确保已使用应用程序部署了PDB（发布PDB就足够了）。然后，如果在生产计算机上安装并运行Visual Studio远程调试器，则可以从本地计算机进行调试。部署的计算机上的应用程序的PDB文件应该与您的本地版本匹配，因为我认为远程调试器不会进行任何类型的同步。
答案 2 :(得分：0)
使用状态消息和日志文件来至少识别导致错误的代码行。
答案 3 :(得分：0)
我建议您使用Enterprise Library中的异常处理应用程序块 使用此功能，您可以将错误消息记录到您的电子邮件/数据库/文本文件等。等等。 这样你就可以准确找出错误背后的原因。