Mixing Debug and Release Files in an MFC Project

Last reviewed: July 31, 1997
Article ID: Q117499

1.00 1.50 1.51 1.52 | 1.10 2.0 2.10 4.00

WINDOWS             | WINDOWS NT

kbtool

The information in this article applies to:

The Visual Workbench included with:

  - Microsoft Visual C++ for Windows, versions 1.0, 1.5, 1.51, and 1.52
  - Microsoft Visual C++, 32-bit Edition, version 1.0, 2.0, 2.1, and
    4.0

The information in this article is included in the documentation starting with Visual C++ 5.0. Look there for future revisions.

SUMMARY

When building large Microsoft Foundation Class (MFC) applications, the debug information can take up a lot of disk space. In order to reduce the size of the application, there are several methods by which you can remove the debugging information from some of the modules in the project and/or from the MFC libraries themselves. Moreover, starting with Visual C++ 32-bit Edition version 2.0, the Visual Workbench supports per-file build rules which can greatly reduce the amount of debug information that is generated for an application.

MORE INFORMATION

The following are among the methods available to reduce the amount of debugging information included in a project:

Method 1: Use per-file build options

If you are using Visual C++ 32-bit Edition version 2.x or 4.0, this is the easiest method. It enables you to specify the /Zd (line numbers only) option, among others, for specific files. Doing so can greatly reduce the amount of debug information that is per module.

To set the /Zd switch: 1. Open the Project Setting dialog box.

Click on the desired file in your Debug target's tree view to highlight it.
Select the C/C++ Tab.
With the General catagory selected, select "Line Numbers Only" from the Debug Info list box.

Method 2: Build the Debug MFC Libraries with Reduced CodeView Information

Try rebuilding the MFC libraries using the /Zi compiler switch instead of the /Z7 compiler switch. This builds a program database (.PDB) file for the entire library that contains all of the symbolic type information. Each time the compiler generates type information for a new symbol when compiling the source files, it checks the .PDB file to see whether this type is already present. If so, the type is not added.

Method 3: Build the Debug MFC libraries Without CodeView Information

This is the one of the easiest methods for reducing the size of your debug executable file. The only thing lost by using this method is the ability to step into the MFC code itself. All other debug facilities, such as ASSERTs and TRACEs, remain.

The following command builds the medium-memory model debug MFC library without CodeView information for Windows (MAFXCWD.LIB):

   NMAKE MODEL=M TARGET=W DEBUG=1 CODEVIEW=0

Further information on building a static link library variant can be obtained from the README.TXT file that ships with Visual C++ and can be found in xxxx\MFC\SRC\README.TXT (where xxxx is the directory name for the Visual C++ product - by default, MSVC for Visual C++ versions 2.x and earlier, MSDEV for Visual C++ version 4.0).

Method 4: Use the Full Debug MFC Libraries with Only Selected Debug Modules

This method allows you to step into the MFC source code as well as providing the other debug facilities. This makes use of both the Debug and Release modes of the Visual Workbench makefile, thus making necessary the changes described below (and also making a "rebuild all" necessary when a full release build is required):

For Visual C++ versions 2.x and earlier, follow these steps:

Choose the Project dialog box from the Options menu and check "Use Microsoft Foundation Classes". Also choose Release for the Build Mode.
Select Compiler and the Preprocessor category. Change "NDEBUG" to "_DEBUG" under "Symbols and Macros to define" and then choose the "OK" button.
Select Linker and the Input category. Change the MFC library in the Libraries setting to the debug version (MAFXCWD.LIB for Windows, NAFXCWD.LIB for Windows NT), then choose the "OK" button.
Choose the "OK" button again to exit the Project dialog box, then choose Rebuild All from the Project menu. This removes all debug information from your modules, but does not affect the MFC debug information.
Choose Project from the Options menu and then choose Debug for the Build Mode from the Project dialog box. Choose the "OK" button.
Open each file in which you want to include debug information and then choose Compile File from the Project menu.
NOTE: If you are using an AppWizard-generated application or have precompiled headers, you either have to recompile them before compiling the other modules or turn off the precompiled headers. Warning C4650 and error message C2855 are returned if this is not done correctly.
Select Build from the Project menu. The following message appears:
```
      The current project has changed. Would you like to build the affected
      files?
```
Choose "No," because all the object files are up to date, but Visual C++ "knows" that they are of different build types.

For Visual C++ version 4.0, follow these steps:

Choose Set Default Configuration... from the Build menu and select the release version of the project in the Default Project Configuration dialog box.
Choose Settings... from the Build menu to open the Project Settings dialog box.
Select Use MFC in a Static Library from the Microsoft Foundation Classes list box in the General Tab.
Select Preprocessor from the Category list box in the C/C++ Tab. Change "NDEBUG" to "_DEBUG" in the Preprocessor Definitions edit field.
Select Input from the Category list box in the Link Tab. Enter NAFXCWD.LIB in the Object/libraries modules edit field.
Choose the "OK" button to save the new build options and close the Project Settings dialog box.
Choose Rebuild All from the Build menu. This removes all debug information from your modules, but does not affect the MFC library.
For each project file in which you want to include debug information, follow the steps of Method 1, above, specifying the desired degree of debug information.
NOTE: If you are using an AppWizard-generated application or have precompiled headers, you either have to recompile them before compiling the other modules or turn off the precompiled headers. Warning C4650 and error message C2855 are returned if this is not done correctly.
Select Build <EXE name> from the Build menu to rebuild those project files that are out of date.

This includes debug symbols for the modules selected in either step 6 (Visual C++ versions 2.x and earlier) or step 8 (Visual C++ version 4.0). You are able to set breakpoints only within modules you have compiled using debug information. If you need to reduce the executable size even further, you can use the MFC debug libraries as described in Method 3, above.

Method 5: Use an External Makefile to Mix Release and Debug Information

This technique eliminates the need to alter the affects of a release build. It also eliminates the need to manually recompile each module to keep the object files up to date. However, you can no longer change compile and link options from within the Visual Workbench. The makefile has to be maintained manually. The important thing to keep in mind is that if you want to link with the debug MFC libraries you must have "_DEBUG" defined for every module. Conversely, if you want the release MFC libraries, you must have "NDEBUG" defined. For more information on writing external makefiles, see "Managing projects with NMAKE" in the TechNote Viewer, which is located in the Visual C++ program group, or consult the "NMAKE Reference" in the Visual C++ Books Online.

KBCategory: kbtool
KBSubcategory: VWBIss
Additional reference words: 1.00 1.10 1.50 1.51 1.52 2.00 2.10 2.50 2.52
2.52 3.00 3.10 4.00
Keywords : VwbIss kbtool
Technology : kbMfc
Version : 1.00 1.50 1.51 1.52 | 1.10 2.0 2
Platform : NT WINDOWS

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: July 31, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.