C# - .net 中是否真的需要调试构建
如果发布版本生成 .pdb 文件，并且您可以单步执行每一行，放置断点等，那么为什么还要费心构建我的组件的“调试”版本呢？
我在我的项目中使用 C#，并且在调试发行版本时没有遇到问题。 在 C++ 中，我在调试优化代码时遇到了问题，但在 C# 中它工作得很好。 我不是在谈论像 if(false) 这样愚蠢的代码块...
If the release version produces .pdb files and you can step into every line, put breakpoints etc then why ever bother to build a "debug" version of my components?
I'm using c# for my projects and i didn't have problem debugging release versions. In C++ i had problems debugging optimized code but in C# it works fine. I'm not talking about silly code blocks like if(false)...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
发布版本更加优化，例如，当我调试发布版本时，当运行时不使用局部变量的值时，局部变量的值会消失，这让我很烦恼。
The release builds are more optimized, e.g. when I debug release builds it annoys me that local variable's values disappear when their values are not going to be used by the runtime.
原因之一是附加与启动。
如果您在 .Net 中启动 Retail 进程，则调试几乎与启动 Debug 进程一样好。 您可能不会注意到调试体验有任何差异。
Attach 是一种完全不同的球类游戏。 C# 和 VB 都通过零售版本的 /optimize+ 标志。 这将在程序集级别嵌入DebuggableAttribute，而无需DebuggingMode.DisableOptimizations 标志。 在进程启动期间，VS / CLR 将进行通信以基本上忽略这一事实并禁用影响调试的 JIT 优化。 在附加过程中，不会发生此类情况，JIT/CLR 将根据其需要进行优化。 我向你保证，在这种情况下调试体验会更差。
中进行试验
One reason is attach vs. launch.
If you launch a Retail process in .Net, the debugging is almost nearly as good as launching a Debug process. You will likely not notice any difference in your debugging experience.
Attach is a completely different ball game. Both C# and VB are passed the /optimize+ flag for retail builds. This will embed the DebuggableAttribute at the assembly level without the DebuggingMode.DisableOptimizations flag. During a process launch, VS / CLR, will communicate to essentially ignore this fact and disable JIT optimizationss that impact debugging. During attach, no such item happens and the JIT/CLR will optimize to it's hearts content. I guarantee you, the debugging experience is much worse in this case.
You can experiment with this in VS
在 (c#) winforms 中，您无法在发布版本中编辑和继续。
In (c#) winforms you cannot edit&continue in release builds..
除了其他答案之外，我还使用自动生成的 #define DEBUG 来更改发生未捕获的异常时的行为：
Apart from the other answers, I use the automatically generated
#define DEBUGto change behaviour when an uncaught Exception occurs:有几个原因：
当然，其中很多内容都可以在构建配置中进行更改。 一种相当常见的方法是保留默认设置，除非在发布版本中包含更多调试信息，这可以为您提供更有用的堆栈跟踪（如果您这样做，则可以提供更好的调试体验） 使用调试器）。
There are a few reasons:
Debug.Assertetc will be removed.A lot of this can be changed in the build configuration, of course. One fairly common approach is to leave the default settings alone except for including more debugging information in a release build, which can give you more useful stack traces (and allow a better debugging experience if you do use the debugger).
发布版本比调试版本执行更多优化，但是调试版本也会稍微改变 GC 的行为，以确保当您处于调试会话期间时不会从您的下方收集对象。 调试构建还会阻止 JIT 期间发生某些优化，这将对调试会话产生负面影响。
Release builds perform additional optimizations than debug builds, however a debug build also slightly changes the behavior of the GC to ensure that you don't get an object collected out from under you while you are in the middle of a debug session. Debug builds also prevent certain optimizations from occuring during JIT which will have a negative impact on your debug session.
我同意 Lennaert 的观点 - 我倾向于在构建之间进行不同的错误处理。 例如，对于某些应用程序，我在调试版本中是超级肛门。 前置条件和后置条件、断言、异常等。我基本上是试图强迫开发人员正确使用我的库。 另一方面，在发布版本中，我放宽了条件以提高性能。
I agree with Lennaert - I tend to do different error handling between the builds. For example, for some of the apps I am super anal in the debug build. Pre- and post-conditions, assertions, exceptions, etc. I basically am trying to force the developer to use my library correctly. In the release build, on the other hand, I relax the conditions to improve performance.
当您使用按契约设计时，拥有两个版本非常重要 - 发布版本不检查先决条件、后置条件和 >类不变量和检查它们的调试类（通过断言）。
在某些情况下，前置条件检查可能会在发布模式下保持活动状态（搜索相关问题），但这不会改变整个情况。
在开发阶段，您检查所有合同假设，当您发布时，您不再检查它们 - 您知道您已经测试了代码并且它可以工作，因此您只需依赖之前的假设——这就是它们最初被设计的原因。
When you use Design by Contract, it is important to have two builds - the release one which doesn't check Preconditions, Postconditions and Class Invariants and the debug one which checks them (via assertions).
In some situations, Precondition checks may be left active in release mode (search for related questions), but that doesn't change the whole story.
In the development phase you check all of your contract assumptions, and when you release, you don't check them anymore - you know you have tested the code and it works, so you just rely on your previous assumptions - that's why they were intended for in the first place.