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