Mar*_*ark 3 .net debugging production-environment visual-studio
我们有一个用C#.NET编写的应用程序,目前在生产环境中使用.显然使用了发布版本.
不幸的是,有时应用程序在某些条件下行为不端,我们无法弄清楚原因.我们无法在内部重现这个问题.是的,更多的跟踪会有所帮助,但通常是在您意识到应该实施更多跟踪之后.
使用常规,逐行,Visual Studio Attach-to-Process类型调试来调试该安装的最佳方法是什么.是否在客户机器上安装VS的快速版本并用调试版本替换dll?只发送PDB和特定的源文件是否足够?有没有更好的办法?最终目标是拥有类似环境的开发来调试问题.
远程调试是一个很好的功能,但它很少在生产环境中使用,因为它需要很难实现的域(您自己和客户)之间的双向信任(两家公司的管理员都强烈反对这个想法)
请参阅跨域远程调试
但是,随应用程序发送PDB文件会有所帮助.您可以要求您的客户使用Clr Debugger(DbgCLR.exe)与VS Debugger相比它有一些限制,但它仍然是一个可以完成工作的调试器,它是.NET SDK的一部分.如果无法使用Clr Debugger调试问题,客户可以尝试在其生产环境中安装VS的试用版,并为您提供远程桌面连接(如果管理员允许您这样做).我想90天的试用期足以解决问题
您还可以尝试构建一个类似于客户的测试环境 - 限制(或增加)CPU数量,内存等,以尽可能匹配物理条件.如果您认为某些其他第三方软件或不存在的注册表记录会影响您的程序,请让您的客户创建其Windows的虚拟映像.
但是,我的经验是,由于多个用户的并发访问(死锁,竞争条件,First Wins/Last Wins场景中的逻辑错误行为),因此在50%中出现这种"不可重现"的错误.在大多数情况下,即使您在客户计算机上安装VS,也无法调试这些错误(如果您在非高峰时间运行此操作),因为您需要在不同的计算机上同时运行至少2个客户.
因此,在寻找为客户提供调试的选项时,请继续努力改进跟踪和监控功能.跟踪和性能计数器通常是您在生产环境中唯一的朋友.
归档时间: |
|
查看次数: |
2129 次 |
最近记录: |