不通过调试器运行业务关键型C#控制台应用程序的原因？

Question

我正在寻找一些可以用来说服同事的谈话要点,通过简单地打开Visual Studio并在调试模式下运行应用程序来运行24/7生产应用程序是不行的.

运行已编译的控制台应用程序与在调试模式下运行相同的应用程序有何不同？

有时您会在实时设置中使用调试器吗？(实时:意味着连接到面向客户的数据库)

假设通过调试器运行实时配置总是一个坏主意我错了吗？

Answer 1

在调试器下运行时会降低性能(更不用说Bruce提到的复杂性问题),并且在发布模式下编译时没有任何东西可以阻止你获得与在调试器下运行相同的功能 - 你总是可以将程序设置为记录未处理的异常并生成核心转储,即使在重新启动应用程序后也可以调试问题.

此外,手动管理需要24/7可用性的应用程序听起来是完全错误的.您应该使用计划任务或某种自动流程重启机制.

稍微退一步,这个问题可能会对影响你的团队提供一些指导.

Answer 2

如果性能足够好的话,在调试中运行它没有问题.令我感到奇怪的是,您作为用户运行业务关键的24/7应用程序,甚至可能在工作站上运行.如果您想确保稳健性和可用性,您应该考虑在除应用程序之外没有人使用的专用硬件上运行此功能.如果您确实在用户计算机上运行此操作,则可以轻松发生事故,例如关闭"错误的"可视化工作室或使计算机崩溃等.

在调试中运行应该在测试环境中完成.在我工作/工作的地方,我们通常有三个环境,生产,发布和测试.

生产

• 专用硬件
• 访问受限,通常只有主要的开发人员/技术
• 版本控制,来自SVN/CVS的某个标记版本
• 运行已升级到生产状态的最新稳定版本

发布

• 专注于硬件
• 完全访问所有开​​发人员
• 版本控制,来自SVN/CVS的某个标记版本
• 运行下一个版本的产品,尚未升级到生产状态,但可能会.如果你愿意的话,"黄金".

测试

• 虚拟机或ouse硬件
• 完全访问权限
• 没有版本控制,可能是下一个版本,下一个版本,或者只是某个人想要在"近端环境"下测试的自定义版本

这样我们就可以在Release中轻松测试新版本,甚至可以在那里调试它们.在测试环境中,它是任何事情.如果有人想要测试涉及多个盒子(你自己的盒子)的东西,那就更好了.

通过这种方式,它可以保护您免受通过使用专用测试机器而没有经过充分测试的快速攻击,但仍允许您在紧急情况下释放这些黑客.