20.6 Release and Debug builds

In Visual Studio, you have the option of building two different versions of your executables: the Debug or the Release version. You can switch between the one and the other using the combo box in the Build toolbar (if this toolbar is visible), or by using Build | Configuration Manager [this is Build | Set Active Configuration with Version 6.0]. The default setting is for Visual Studio to build the Debug version.

The difference between the Debug and the Release version is that the Debug executable includes debugging information, which makes the *.exe considerably larger.

What is debugging information anyway? Well, when you make the binary version of a program, things like the English names of variables get thrown away, not to mention the text of the source code. But you need to be able to get back all this stuff if you are debugging the program.

When you debug a program it actually runs inside another program, the debugger itself. If your program crashes, the debugger will normally highlight the line where the crash happened. Note that programs do run a bit slower inside the debugger. But while you are developing a program you never know when it will crash, so it is usually best to be inside the debugger.

Ordinarily you want to build the Debug version while you are developing the program, and once you start to distribute it to other people, you will want to use the Release version. The reason why you want to distribute the Release version is that (a) it will be a smaller file than the Debug version, and (b) the Release version will run faster, sometimes as much as 30% faster.

If you look in your source-code directory after a build, you'll notice that there will be some subdirectories in addition to the res subdirectory: the Debug subdirectory and/or the Release subdirectory. The res subdirectory, of course, has the necessary resource files and was part of the source code. The Debug subdirectory and/or the Release subdirectory are put there by Visual Studio when you build the Debug and/or Release versions. In building these executables, Visual Studio makes a number of intermediate files that are stored in the corresponding subdirectories.

By default, Visual Studio will put the Debug and Release executables in the corresponding Debug and Release subdirectories. But the author has edited the project file so as to put the executables in the same location as the source code.

You can control the name and location of your output file by first opening View | Solution Explorer and making sure the Pop project is highlighted and then editing the View | Property Pages... | Linker | Output File line. [In Version 6.0, this is the Project | Settings | Link | Output File Name edit box.] The default might be Debug\Pop.exe, but if you want the code for the Debug executable to be with your source, you might enter something like Pop 25_5(Debug Build).exe.

How would you change the name and location of the Release executable to, say, Pop 25_5(Release).exe? Look at the upper left-hand corner of the Property Pages dialog box you just opened [called the Settings dialog box in Visual 6.0]. There is a little Configuration combo box that you can set to Debug, Release, or All Configurations. [The combo box is called Settings for in Version 6.0.] When you switch this selection between the Debug and the Release selection, you'll notice that the entries in the dialog box change. Changing this combo box changes which configuration's settings are being shown and possibly altered by the project Property Pages dialog box [called Settings dialog box in Version 6.0.]

The Link project settings dialog in Visual Studio.NET


By the way, you might think that by changing the active configuration setting for the combo box, you might change which configuration was being built. This is not the case! The only way to change which version is being built is by using the completely separate dialog box Build | Configuration Manager [called Build | Set Active Configuration in Version 6.0].

    Part I: Software Engineering and Computer Games
    Part II: Software Engineering and Computer Games Reference