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

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

运行编译的控制台应用程序与在调试模式下运行同一应用程序有什么不同

是否曾经有过在实时设置中使用调试器的情况？（实时：意味着连接到面向客户的数据库）

---

我是否错误地认为通过调试器运行实时配置总是一个坏主意

我不能代表每个人的经验，但对我来说，VisualStudio经常崩溃。它不仅会导致自身崩溃，还会导致explorer崩溃。附加组件和插件加剧了这种情况。我不确定它是否曾经被测试过像操作系统那样，每天24/7地运行

你的应用程序的运行基本上是由第二个应用程序的巨大庞然大物支配的，听起来它比你的应用程序大几个数量级，也更复杂。您只会收到bug报告，其中大多数都会涉及visual studio崩溃

---

另外，您是否为生产机器的visual studio许可证付费？

在调试器下运行时，您的性能会降低（更不用说复杂性问题了），在发布模式下编译时，没有什么可以阻止您获得与在调试器下运行相同的功能——您可以随时将程序设置为，这样即使在重新启动应用程序后也可以调试问题

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

---

退一步，可能会提供一些关于影响团队的指导。

我们从不通过调试器运行它。有些编译器选项可能会意外打开/关闭。优化没有打开，在生产环境中运行它会带来巨大的安全风险

一般来说，当你在调试器下运行一个程序时，实际上是在运行两个进程——目标进程和调试器进程——并将它们紧密地联系在一起。因此，存在意外影响和错误（不在生产运行中）的机会。当然，编写调试程序的人员尽最大努力将这些影响降至最低，但全天候运行该场景可能会暴露确实存在的任何问题

如果您试图跟踪特定的故障，有时在调试器下运行是最好的解决方案；但即便如此，通常启用某种类型的跟踪也是一种影响较小的解决方案，同样有效

---

调试器也在使用资源-这可能是一个问题，具体取决于机器和应用程序。如果您需要更具体的示例，说明使用调试器24/7时可能出错，请告诉我。

您肯定不希望需要24/7时启动的应用程序从调试器手动运行，而不管性能问题如何。如果你必须说服你的同事，那就找一份新工作

---

我有时会使用实时调试器（即针对实时客户数据）在无法在测试环境中准确再现生产数据的情况下调试与数据相关的应用程序问题。

只要性能足够好，在调试中运行它本身就没有问题。让我感到奇怪的是，您正在以用户的身份运行业务关键型的24/7应用程序，甚至可能是在工作站上。如果您想确保健壮性和可访问性，您应该考虑在专用硬件上运行此操作，除了应用程序之外，没有人使用它。如果您确实在用户计算机上运行此操作，则很容易发生意外，例如关闭“错误”的visual studio，或使计算机崩溃等

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

生产

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

发布

• 专用硬件
• 对所有开发人员的完全访问
• 版本控制，来自SVN/CVS的特定标记版本
• 运行产品的下一个版本，尚未升级到生产状态，但可能会升级到生产状态。“黄金”，如果你喜欢的话

测试

• 虚拟机还是虱子硬件
• 完全访问
• 没有版本控制，可以是下一个、下一个版本，或者只是有人想在“近prod环境”上测试的自定义版本

通过这种方式，我们可以轻松地在发行版中测试新版本，甚至在发行版中调试它们。在测试环境中，什么都可以。如果有人想测试涉及多个盒子（你自己的）的东西，这就更重要了

---

通过这种方式，它将保护您免受没有通过专用测试机器进行充分测试的快速黑客攻击，但仍然允许您在紧急情况下释放这些黑客攻击。

除了调试代码可能具有不同的代码路径（

#ifdef、debug.Assert（）等）代码方面，它将运行相同的代码

有点吓人-设置断点、设置要执行的下一行代码、交互式异常弹出窗口和visual studio下运行的“不稳定”。还有一些调试器选项，允许您在异常发生时始终中断。如果您没有正确编写代码，即使检查类也会产生副作用。。。我当然不想像正常的24x7流程那样做

从调试器运行的唯一原因是调试应用程序