我应该如何在Visual Studio中使用调试/发布模式？

Question

我通常在我的工作机器上本地测试代码，然后将其移动到开发环境，最后再发布到生产环境。对于这种情况，使用调试/发布模式的最佳方式是什么？我只需要关心我的机器上的调试模式吗？我应该发布调试模式还是发布模式到开发环境？我知道我应该使用发布模式发布到生产环境。以前我没有注意到这些问题，所以一直在调试模式下工作，我知道这是不正确的。

编辑：谢谢回答。看起来只在自己的机器上使用调试模式是个好主意。即使它在开发机器上，它基本上也是向公众（同事、QA）发布，因此应该处于发布模式。当然，在发布到生产环境时应该是发布模式。

- Hertanto Lie

Answer 1

发布应用程序时，您应该使用发布模式。发布模式是专门用于发布应用程序的。生成的代码通常更具性能，并且许多与应用程序开发阶段相关的检查都被移除了。

在正常的开发工作中，您应该使用调试模式。大多数编程语言会在调试模式下插入额外的检查。这些检查可以发现更多的错误，但往往会使应用程序变慢一些。

然而，在开发过程中，您也必须对发布模式进行重要的测试。因为客户只会看到您产品的发布模式版本，而某些错误可能仅存在于调试或发布模式中。在调试模式中插入的错误检查可能会引入副作用，掩盖应用程序中真正的错误。

- JaredPar

---

@JaredPar “在调试模式下插入的错误检查可能会引入副作用，从而隐藏应用程序中真正的错误。” -- 你能详细说明一下吗？ - TGnat

@TGnat，有一些明显的情况会导致检查改变全局状态（虽然这种情况很邪恶，但确实存在）。更微妙的一种情况是，仅运行一个检查就会改变应用程序的时间。我见过许多线程问题，其中昂贵的调试模式检查隐藏了潜在的时间问题，因为在 DEBUG 模式下，一个线程需要花费更长的时间，而在 RELEASE 模式下则需要较短的时间。这使得其他线程可以达到已完成的状态，并呈现出应用程序工作的外观。一旦在 RELEASE 模式下移除检查，线程就会更快地运行并暴露竞争条件。 - JaredPar

Answer 2

我采用以下方法：

• 在我的工作站上进行代码/调试周期：DEBUG
• 在我的工作站上运行单元测试：DEBUG
• 在我的工作站上进行性能分析：RELEASE
• 夜间构建和自动化测试：RELEASE（执行无人值守安装）
• 由QA团队进行实际测试：RELEASE

所有测试都必须至少在发布版上进行，因为这是你将要交付的产品。在Debug版本上进行性能分析通常是没有意义的（特别是在C++中），因为Debug堆有很多额外的检查，会完全改变典型应用程序的性能特征。

- Daniel Earwicker

Answer 3

一般来说，总是要将Release版本部署到生产环境中。Debug会增加程序集的体积并降低性能。

如果你正在开发ASP.NET应用程序，保留Debug模式实际上会改变JIT编译器编译页面的方式和时间，并且显著降低性能以提供更好的交互式调试功能。

至于部署到开发环境的构建版本，如果你正在对开发环境运行单元测试，那么部署Debug构建版本可能是一个好主意，这样当测试失败或出现异常时，你可以获得最多的调试信息。然而，希望还有一个额外的测试或预生产环境，在那里可以运行集成测试并进行手动测试。该测试/预生产环境应该绝对使用Release版本，以便在进入生产环境之前看到真正的性能和编译问题。

如果没有这个中间的测试/预生产级别，那么我建议你在Dev环境中使用Release。换句话说，你应该在生产之前的至少一个级别中使用Release配置。

如果您想了解配置文件的更多用法，我有一篇专门介绍Silverlight的博客文章(http://blog.tonyheupel.com/2009/04/environment-specific-service-references.html)。其中包含一个链接指向Scott Hanselman关于不同环境下构建配置的通用文章。

- Tony Heupel

Answer 4

默认情况下，发布版本将使用更多的优化器开关进行编译，这将导致更快、更小的代码，通常这是您要向客户发布的内容（因此称为“发布”）。调试版本几乎不进行优化，这意味着在使用调试器时，底层机器代码更接近源代码，有助于调试。此外，默认情况下，调试版本会插入额外的运行时代码检查，可以捕获常见错误，例如访问未初始化的数组成员。请注意，您可以使用调试符号构建发布版本，但调试器将更难将当前语句映射到适当的源代码行。

- John Källén