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

How should I use debug/release mode in Visual Studio?

提问by Hertanto Lie

I usually test my code locally on my work machine and then move it to development environment and then finally to production environment. What is the best way to use debug/release mode for this scenario? Do I only need to care about debug mode in my machine? Should I publish debug mode or release mode to development? I know probably I should publish using the release mode to production. I didn't really pay attention to all of this before so I have been working only in debug mode all the time, which I know I shouldn't.

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

Edit: Thanks for the answers. It looks like it's a good idea to only use debug mode in my own machine. Even though it's in development machine, it's basically releasing to the public (co-workers, qa) so it should be in release mode. And of course it should be release mode when releasing to prod.

编辑：感谢您的回答。看起来只在我自己的机器上使用调试模式是个好主意。即使它在开发机器中，它基本上也向公众（同事，qa）发布，所以它应该处于发布模式。当然，发布到 prod 时应该是发布模式。

回答by JaredPar

When releasing / publishing an application you should do so in Release mode. Release mode is for just that, releasing applications. The code produced is typically more performant and many removes many checks that are more associated with the development phase of an application.

在发布/发布应用程序时，您应该在发布模式下进行。发布模式就是为了这个，发布应用程序。生成的代码通常具有更高的性能，并且许多代码删除了与应用程序开发阶段更相关的许多检查。

In a typical day, you should be developing in Debug mode. Most languages insert extra checks into a debug mode application. These spot more bugs but tend to slow down the application a bit.

在典型的一天中，您应该在调试模式下进行开发。大多数语言会在调试模式应用程序中插入额外的检查。这些会发现更多错误，但往往会稍微减慢应用程序的速度。

Yet you must also do siginificant testing of Release mode as part of your development process. Customers will only actually see the Release mode version of your product and it's possible for bugs to be Debug / Release mode specific. The bug checks inserted in debug mode can introduce side effects that hide real bugs in your application.

然而，作为开发过程的一部分，您还必须对 Release 模式进行大量测试。客户实际上只会看到您产品的发布模式版本，并且错误可能是特定于调试/发布模式的。在调试模式下插入的错误检查可能会引入隐藏应用程序中真正错误的副作用。

回答by Daniel Earwicker

I follow this approach:

我遵循这种方法：

• code/debug cycle on my workstation: DEBUG
• running unit tests on my workstation: DEBUG
• profiling on my workstation: RELEASE
• overnight build and automated tests: RELEASE (performs an unattended install)
• hands-on testing by QA team: RELEASE

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

All testing must be carried out at least on the release build, because it's what you're going to ship. Profiling on the debug build is usually pretty pointless (especially in C++) because debug heaps have a lot of extra checking that totally changes the performance profile of a typical application.

所有测试必须至少在发布版本上进行，因为这是您要发布的内容。在调试构建上进行分析通常毫无意义（尤其是在 C++ 中），因为调试堆有很多额外的检查，这些检查完全改变了典型应用程序的性能配置文件。

回答by Tony Heupel

In general, ALWAYS deploy Release builds to production. Debug will add to your assembly weight and degrade performance.

通常，始终将发布版本部署到生产中。调试会增加您的程序集重量并降低性能。

If you are developing ASP.NET applications, leaving Debug mode on actually changes how/when your pages are compiled by the JIT compiler and significantly degrades performance to add better interactive debugging ability.

如果您正在开发 ASP.NET 应用程序，启用调试模式实际上会改变 JIT 编译器编译页面的方式/时间，并显着降低性能以增加更好的交互式调试能力。

As far as which build to deploy to development...if you are running unit tests against development, it is probably a good idea to deploy the Debug build so you can get the most debugging information when tests fail or exceptions occur. However, there is hopefully an additional Testing or Pre-Production environment where you can have your integration tests running and manual tests are performed there. That Testing/Pre-Prod environment should DEFINITELY be using Release builds so that you can see the true perfomance and compilation issues before going to Production.

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

If you don't have this intermediate Testing/Pre-Prod level, then I would suggest running your Dev environment with Release. In other words, you should run at least one level before production in Release configuration.

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

For more information on what you can do with configurations, I have a blog post specifically for Silverlight (http://blog.tonyheupel.com/2009/04/environment-specific-service-references.html). In there is a link to Scott Hanselman's more generic article on build configurations and different environments.

有关配置的更多信息，我有一篇专门针对 Silverlight 的博客文章 ( http://blog.tonyheupel.com/2009/04/environment-specific-service-references.html)。里面有一个链接，指向 Scott Hanselman 的关于构建配置和不同环境的更通用的文章。

回答by John K?llén

By default, the release build will be compiled with more optimizer switches on, which will result in faster and smaller code, which is typically what you want to release to customers (hence the name). T

默认情况下，发布版本将在更多优化器开关的情况下编译，这将导致更快、更小的代码，这通常是您想要发布给客户的代码（因此得名）。吨

he debug build does almost no optimizations, which means that when using the debugger, the underlying machine code corresponds more closely to the source code, which assists with debugging. Also, the debug build by default inserts extra runtime code checks which will catch common errors like accessing uninitalized array members.

debug build 几乎不做任何优化，这意味着在使用调试器时，底层机器代码与源代码更接近，这有助于调试。此外，默认情况下调试构建会插入额外的运行时代码检查，这些检查将捕获常见错误，例如访问未初始化的数组成员。

Note that you can build release builds with debugging symbols, it just becomes harder for the debugger to map the current statement in the machine code to the appropriate line of source.

请注意，您可以使用调试符号构建发布版本，调试器将机器代码中的当前语句映射到适当的源代码行变得更加困难。