Geek Answers Handbook

C # - Is there a need to create debugging in .net

If the release version creates .pdb files, and you can go in every line, put breakpoints, etc., then why create a "debug" version of my components at all?

I use C # for my projects, and I had no problems with the debug version of the release. In C ++, I have problems debugging optimized code, but in C # it works fine. I'm not talking about stupid blocks of code like if(false) ...

+4
source share
8 answers

One of the reasons is the launch binding.

If you start the Retail process in .Net, debugging is almost as good as starting the debugging process. You probably won't notice any difference in your debugging experience.

Attach is a completely different ball game. Both C # and VB are passed with the / optimize + flag for retail builds. This will add assembly level DebuggableAttribute without the DebuggingMode.DisableOptimizations flag. When the process starts, the VS / CLR will bind to essentially ignore this fact and disable JIT optimization that affects debugging. During attachment, such an element does not occur, and the JIT / CLR will optimize the content of hearts for it. I guarantee that in this case the debugging experience is much worse.

You can experiment with this in VS

  • Turn off build for release
  • CTRL + F5 to run without debugging
  • Attach to the process.
+7
source

Release plugins are more optimized, for example. when I debug a release, it annoys me that the local values ​​of variables disappear when their values ​​are not used by the runtime.

+8
source

In (C #) winforms, you cannot edit and continue in build versions.

+5
source

Among other answers, I use the automatically generated #define DEBUG to change behavior when an uncaught exception occurs:

  • If you work in Release mode, show a nice message to the user and, if necessary, write down the error,
  • If you are working in debug mode, do nothing (which will cause the debugger to break)
+3
source

There are several reasons:

  • By default, the release build does not include as much debugging information in the PDB file. I believe that this option was more noticeable - now it is located in the "Advanced Settings" section of the "Output" section with possible values ​​of "none", "full" (by default for debugging collections) and "pdb-only" (by default builds for release).
  • Release builds are optimized by default: although this does not make almost the same difference in C # as in other languages ​​(e.g. C ++) due to the fact that JIT does most of the work, there may well be some differences that make It’s more difficult to debug the build of the release.
  • By default, the release assembly does not define the DEBUG character, so any calls to Debug.Assert , etc. will be deleted.

Many of them can be changed in the assembly configuration, of course. One fairly common approach is to leave the default settings separate, with the exception of including more debugging information in the release assembly, which may give you more useful stack traces (and will allow better debugging experience if you use a debugger).

+2
source

Release builds perform additional optimizations than debug builds, but debug builds also slightly modify the behavior of the GC to ensure that you don’t get an object collected from under you when you are in the middle of a debugging session. Debug builds also prevent certain optimizations during JIT that will negatively impact your debugging session.

0
source

I agree with Lennaert - I try to do different error handling between assemblies. For example, for some applications, I have a super anal in the debug assembly. Preconditions and post-conditions, statements, exclusions, etc. I am basically trying to get the developer to use my library correctly. On the other hand, in the release build, I relax the conditions for better performance.

0
source

When you use Design by contract , it is important to have two assemblies - the final assembly, which does not check the Prerequisites , Postconditions and Class Invariants, and the debugging, which checks them (through statements ).

In some situations, prerequisite checks may be left active in release mode (search for related issues), but this does not change the whole story.

At the development stage, you check all of your contractual assumptions, and when you release, you no longer check them - you know that you tested the code and it works, so you just rely on your previous assumptions - which is why they were intended in the first place.

0
source

More articles:


All Articles