Purpose of debug and release configurations
Hi there!
I have posted the same question before without finding an anwser. After spending some time with VS I may now be more exprerienced to phrase the question better!
The following applies to VS2005 beta 2. Follow the steps:
- Open VS and create a new windows app (I use VB but I guess the same goes for C#)
- Hit F5 to run the application. The following files are created under bin\debug:
- WindowsApplication1.exe
- WindowsApplication1.xml
- WindowsApplication1.pdb
- WindowsApplication1.vshost.exe
- Now hit Ctrl+Shift+B to build the application. The following files are created under bin\release (vshost.exe is missing):
- WindowsApplication1.exe
- WindowsApplication1.xml
- WindowsApplication1.pdb
- Close VS, open it again, load the same project and hit Ctrl+Shift+B to build once more. Now all the files are created under bin\release, including vshost.exe!!!
QUESTION1: What's pdb file is doing in the release folder? Isn't it only for debug purposes?
QUESTION2: Why is vshost.exe created in the release folder? And why only the second time? Is it a bug?
QUESTION3: Provided the development process of a specific application does not require any different configuration settings for the debug and release versions, is there a meaning having both these configurations? If you sent the project's output to a colleague to use it would you sent the debug or the release version? (remember, they both include the pdb file).
Thanks,
Dimitris
[1923 byte] By [
papadi] at [2008-2-14]
>> 1. What's pdb file is doing in the release folder? Isn't it only for debug purposes?
Yes but considering that you may need to debugging shipping code, having symbols is very important. We always build both our debug and release configurations with symbols. It adds *very* little overhead to the executables. Obviously you typically don't ship the symbol files to customers. Now you could debug against the "debug" configuration but then again that's not what your customers are using. They have optimized bits, which may behave differently than non-optimized bits. To me key dinstictions between debug and release builds are: how much debug code (asserts, #if, debug libs, etc) is only in the debug build *and* that the release build uses compiler optimizations.
I don't know the answer to #2.
1) The .pdb is very important for release binaries. It makes debugging much more practical. Imagine that you have to debug a problem on a customer computer, who presumably has release binaries, or a bug that only happens in release configuration. For this reason it is important to archive the .pdb's of all the binaries you ship.
2) vshost.exe is a special helper process created in Whidbey that is used to speed up the start of managed debugging. Essentially it pre-creates and pauses a running AppDomain with your assembly in so that when you hit F5 Visual Studio just has to attach to a "hot" process. Sometimes you will see this file, sometimes not; it should not be shipped to customers as it works with VS.
3) Debug and release by default have some configuration differences. For example, Debug is usually not optimized whereas release is -- a tradeoff between speed and debuggability. If you sent the binary to a colleague to use, you might send the debug version (if it might have bugs and speed is not very important) or release (if it is fairly stable and should run as fast as possible).
Thanks for replying Dan!
I can't say you directly answered my questions but you gave me something to think!
1) Ok!
2) I still can't understand what is .vshost doing in bin\release. I know that the release version can also be used to debug an application under Visual Studio, but only if someone manually switches to release configuration and hit F5, which is not the case in my example. Anyway... it's not a big deal anyway. I just want to find out how the system works.
3) I understand the optimazation difference, but as far as stability is concerned, both debug and release output should have the same number of bugs (at least in most of cases).
Bugs existing in release but not debug are not common but certainly happen.
-- timing issues
-- #ifdef differences in the code built in each case
-- invalid compiler optimizations
-- code inside Debug.Assert that changes state and thus does not run in release
-- many other reasons
