 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / CLR / January 2006Debug vs. Release code.
If compiling a C# .NET application, what is the main difference between a debug build vs. a Release build? Either way, the IL can be disassembled back into native source, so I don't understand the difference in the two types of builds. Why shouldn't a debugger be able to debug release code just as easily as debug code? Is it purely based on optimizations or is there more to it?  Signature----------------------------------- Ken Varn Senior Software Engineer Diebold Inc. EmailID = varnk Domain = Diebold.com ----------------------------------- Debug mode means that the debugger and it's symbols will be loaded during run time so that run-time debugging can take place. Release mode does not do this and will "sometimes" result in a smaller assembly size. That said, that's the difference. > If compiling a C# .NET application, what is the main difference between a > debug build vs. a Release build? Either way, the IL can be disassembled > back into native source, so I don't understand the difference in the two > types of builds. Why shouldn't a debugger be able to debug release code > just as easily as debug code? Is it purely based on optimizations or is > there more to it? > Debug mode means that the debugger and it's symbols will be loaded during > run time so that run-time debugging can take place. Release mode does not [quoted text clipped - 8 lines] >> just as easily as debug code? Is it purely based on optimizations or is >> there more to it? Untrue. The debugger is not explicitly loaded for a debug build. If you run a debug build outside a debugger, it will run as a normal application, without optimizations that a release build employs, so it will potentially not perform as well. Cheers, Stu Ken, That is the same thing as what I said. Your comments just refer to running the assembly as a stand-alone assembly and mine were based on the assumption that the OP was talking about running the assembly from within VS.NET. I didn't say anything that was untrue. -Scott >> Debug mode means that the debugger and it's symbols will be loaded during >> run time so that run-time debugging can take place. Release mode does [quoted text clipped - 18 lines] > > Stu > Ken, > [quoted text clipped - 27 lines] >> >> Stu Scott, What I said is very different to your statement. Your original statement is very confusing. You state : "Debug mode means that the debugger and it's symbols will be loaded during run time so that run-time debugging can take place." Your most recent statement is still not quite correct. If a Release build is run in VS.NET, assuming symbols have been generated, it can be debugged, much the same as a debug build. Problems arise when trying to view certain symbols that the optimizer has removed or step through code that has been reorganized during compiler optimization. Reorganization of code is much more apparent in C++ builds than what I have seen in C#, but I believe it still exists. Cheers, Stu > Your most recent statement is still not quite correct. If a Release build > is run in VS.NET, assuming symbols have been generated, it can be > debugged, much the same as a debug build. Not true. 1) Create an ASP.NET project in VB.NET. 2) Switch to release mode. 3) Set a breakpoint. 4) Run the project. It will not stop on your breakpoint. > > Your most recent statement is still not quite correct. If a Release build > > is run in VS.NET, assuming symbols have been generated, it can be [quoted text clipped - 8 lines] > > It will not stop on your breakpoint. Is that true even if you change the settings so that the debug symbols are generated (which they're not by default)? SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too I can't say. I'm not even sure how to change the setting so that debugging symbols are geneterated if you are in release mode. I thought the way you "change the settings" is to switch to Debug mode, hence my point. >> > Your most recent statement is still not quite correct. If a Release >> > build [quoted text clipped - 12 lines] > Is that true even if you change the settings so that the debug symbols > are generated (which they're not by default)? > I can't say. I'm not even sure how to change the setting so that debugging > symbols are geneterated if you are in release mode. I thought the way you > "change the settings" is to switch to Debug mode, hence my point. No - you go to the configuration, the "Build" part of configuration properties, and set "Generate Debugging Information" to True. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too >> Your most recent statement is still not quite correct. If a Release >> build is run in VS.NET, assuming symbols have been generated, it can [quoted text clipped - 8 lines] > > It will not stop on your breakpoint. So what? Symbols are used to 'link' source code to the run time code. You can still attach a debugger to a process even if it is in release mode. You can still set breakpoints (they will be breakpoints on x86) and run the code until the breakpoint is hit. What you cannot do is single step through *source code* in the debugger in a release mode app. Try this. In your release code call Debugger.Break(). Run the code. You'll find that the debugger will be attached at the point where Break is called. Richard SignatureFusion Tutorial: http://www.grimes.demon.co.uk/workshops/fusionWS.htm Security Tutorial: http://www.grimes.demon.co.uk/workshops/securityWS.htm My point was simply that, although it is possible to attach a debugger manually, that is not the default action. And, that although it is possible to generate symbols via a manual setting, it is also not the default. The OP wanted to know what the difference between Debug and Release mode was and what I told him/her is correct (assuming we aren't talking about overriding default behaviors in VS.NET). >>> Your most recent statement is still not quite correct. If a Release >>> build is run in VS.NET, assuming symbols have been generated, it can [quoted text clipped - 22 lines] > > Richard > My point was simply that, although it is possible to attach a debugger > manually, that is not the default action. And, that although it is possible [quoted text clipped - 3 lines] > and what I told him/her is correct (assuming we aren't talking about > overriding default behaviors in VS.NET). Scott - depends what version of VS.NET the OP is referring to - something they do not state. In VS.NET 2005, a Release build of a C# project (by *default*) does generate debug symbols, so I am able to debug a project just fine. For 2003, the default Release build does no generate debug symbols, which I suspect is what you are referring to. In your original reply, the following statement: "Debug mode means that the debugger and it's symbols will be loaded during run time so that run-time debugging can take place." is not fully qualified, and therefore ambiguous. "Run-time" could easily be interpreted by the uninitiated as "a debug build, regardless of how it is started (e.g. in VS.NET or from Windows Explorer), will load the debug symbols and debugger". This is obviously not correct. Again, the OP did not state they were running the project from within VS.NET - they asked "What is the difference between a debug build and a release build". I simply wanted to ensure the original poster was not misinformed. Cheers, Stu >>>> Your most recent statement is still not quite correct. If a Release >>>> build is run in VS.NET, assuming symbols have been generated, it can [quoted text clipped - 20 lines] >> >> Richard In the debug mode the optimizations are not enabled. Example the JIT method inlining is not enabled. > In the debug mode the optimizations are not enabled. Example the JIT > method inlining is not enabled. Yes indeed that is true. > Symbols are used to 'link' source code to the run time code. You can still > attach a debugger to a process even if it is in release mode. You can > still set breakpoints (they will be breakpoints on x86) and run the code > until the breakpoint is hit. What you cannot do is single step through > *source code* in the debugger in a release mode app. Source code debugging should also work if you enable JIT tracking info: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cp conmakingimageeasiertodebug.asp SignatureThis posting is provided "AS IS" with no warranties, and confers no rights. >> Symbols are used to 'link' source code to the run time code. You can >> still attach a debugger to a process even if it is in release mode. [quoted text clipped - 7 lines] > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cp conmakingimageeasiertodebug.asp Hmmm, if that is 100% the case, then there would be no point in symbols, would there? The .NET module, even compiled with /debug, does not contain information about the name of the source file, nor file numbers. That information is held in the symbols file. Generating tracking information, with no knowledge of the location of the local variable, is not much use. The debugger requires symbol files to be able to single step through source code. If you can show me how to do this using GenerateTrackingInfo on a release build executable without symbols files, then I would be very interested. Richard SignatureFusion Tutorial: http://www.grimes.demon.co.uk/workshops/fusionWS.htm Security Tutorial: http://www.grimes.demon.co.uk/workshops/securityWS.htm Yes, symbols are also necessary for source level debugging. It's possible (and I would say, strongly recommended) to generate symbols for release code, even though VS used to make it difficult (I think VS 2003 didn't expose the /debug:pdbonly option; I haven't checked 2005). SignatureThis posting is provided "AS IS" with no warranties, and confers no rights. >>> You can still set breakpoints (they will be breakpoints on x86) and >>> run the code until the breakpoint is hit. What you cannot do is [quoted text clipped - 15 lines] > release build executable without symbols files, then I would be very > interested. >> Your most recent statement is still not quite correct. If a Release build >> is run in VS.NET, assuming symbols have been generated, it can be [quoted text clipped - 8 lines] > > It will not stop on your breakpoint. We are talking about two different things. You are referring to an ASP.NET application, I'm referring to a regular Windows application. Cheers, Stu > Untrue. The debugger is not explicitly loaded for a debug build. If you > run a debug build outside a debugger, it will run as a normal application, > without optimizations that a release build employs, so it will potentially > not perform as well. This is the default behavior. It is possible to change the project settings (if using the IDE) so that DEBUG builds also optimise. Thus, the statement "it will run as a normal application, without optimizations that a release build employs" is only the default behavior and can be changed. Thanks, Shawn Yes, it is possible to have a debug build with optimize code using Visual Studio settings. I had no idea I would create such a debate on this. The main point of confusion that I was having with the issue is that of disassembly of .net code and its relationship to debugging. If a .net disassebler can reconstruct the code from the assembly, then what is the need for debug vs. release code? In particular, I have a problem with having to build in debug mode so that I can get stack trace logs to work in my application to obtain line number and function of errors. Signature----------------------------------- Ken Varn Senior Software Engineer Diebold Inc. EmailID = varnk Domain = Diebold.com ----------------------------------- > Debug mode means that the debugger and it's symbols will be loaded during > run time so that run-time debugging can take place. Release mode does not [quoted text clipped - 8 lines] > > just as easily as debug code? Is it purely based on optimizations or is > > there more to it? My simple answer is: Debug version has some compilation/assembly parameters turned on in the build set that permits easier debugging. In some cases, people write code with #if DEBUG statements that provide additional checks. In this case the DEBUG compilation parameter would be on in the DEBUG build, and not present in the Release build. In this particular case, the IL would be different because some IL code would be suppressed (not generated) in the Release build. As noted earlier, the default settings in Debug builds typically turn on the .PDB (symbol tables) etc. and the Release builds leave them off. I build release versions with symbols turned on (so I can debug the release version in event of a customer problem). The symbol files are not shipped with the release, but they do exist for our use > I had no idea I would create such a debate on this. > [quoted text clipped - 20 lines] > > > just as easily as debug code? Is it purely based on optimizations or is > > > there more to it? Thanks. This is very helpful. In regards to being able to log a stack trace. I am using the StackTrace class. I have noticed that if I do not have the PDB files on the target system, that I cannot get function and line number information in my stack trace. Yet, the standard CLR assemblies can be walked for the same information. Is there anyway that I can have my code build so that I can get useful stack trace info into a log file without having to provide the PDB files? So far having a Debug build seems to be the only way that I know of. Signature----------------------------------- Ken Varn Senior Software Engineer Diebold Inc. EmailID = varnk Domain = Diebold.com ----------------------------------- > My simple answer is: > Debug version has some compilation/assembly parameters turned on in the [quoted text clipped - 34 lines] > > > > just as easily as debug code? Is it purely based on optimizations or is > > > > there more to it?
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.