There are actually four different versions of the executable you might build. As well as choosing between the Debug and the Release build, you can either bind the *.lib version of the MFC code into your executable, or you can have your executable look for the *.dll version of the MFC code run time.
To control this, open View Solution Explorer and make sure the Pop project is highlighted. Then select View Property Pages... General . [In Version 6.0, simply select Project Settings... General. ] And then you can edit the Use of MFC field to be Use MFC in a Static Library or Use MFC in a Shared DLL . The DLL option is the Visual Studio default.
If you look at the Pop project settings, you'll notice that we've chosen to build the Release version with the static library option and the Debug version with the shared DLL option. What do these decisions mean, and why are they reasonable?
When you are using MFC, a lot of the code used by the program lives in external libraries. In Windows a library can have one of two forms, a *.lib file or a *.dll file. Code from a *.lib file gets linked into your executable, which makes your executable bigger “ about 1 Meg bigger in the case of an MFC program. Code from a *.dll file is left out of your executable, and when the executable starts up, it looks on the host computer's hard drive for a copy of the *.dll file it needs, and loads this code into RAM at that time.
The General project settings dialog in Visual Studio.NET
The Link project settings dialog in Visual Studio, Version 6.0
The General project settings dialog in Visual Studio, Version 6.0
If you have an MFC program that expects to find the MFC code in a DLL, when it tries to start up, it will be looking for a file with a name like MFC40.DLL or MFC42D.DLL or maybe MFC42.DLL . Now, Microsoft regularly changes the particular version of the MFC???.DLL distributed with Windows, so there is a very good chance that when you move your executable from your Windows machine to somebody else's Windows machine, your executable is not going to find the *.dll file it needs, and instead of running it's going to show the user a cryptic error message. And even if you give the user a copy of the missing *.dll file, you'll usually find that then there's yet another missing *.dll file that your program needs. And so on. Trying to distribute all the necessary *.dll is in fact too complicated to be practical.
It would seem, therefore, that you'd always want to use the MFC in a static library. But, as we already mentioned, using the static library makes the *.exe bigger. As an illustration, Table 20.1 shows the comparative sizes of the four different builds on the June 21, 2001, version of Pop code.
Table 20.1. Four ways to build an MFC executable.
You will be making lots of Debug builds on your machine as you develop the code, so it will make less work for the linker, and use less space on your hard drive, to use MFC as a DLL for the Debug builds. The Release build, on the other hand, is the 'distributable' version of your code that you plan to show others. For this version, you should use MFC as a LIB.
So, once again, your approach should always be
When you navigate to the project's Use of MFC control as outlined above, the Project Settings dialog box you are using will have in its upper left-hand corner a Configuration combo box [called the Settings For combo box in Version 6.0]. You can first select the Debug configuration and set Use MFC in a Shared DLL , and then select the Release configuration and set Use MFC in a Static Library . From then on when you switch between the two configurations of the workspace, your preferred choice for the Use MFC field will be used. These settings are already in place for the Pop project.
[When using the Learning edition of Version 6.0, you don't have access to the Use MFC in a Static Library option. If you plan to distribute your *.exe to other people, you need to have either a 'Professional' or better edition of Version 6.0 or any version of Visual Studio.NET. Visual Studio.NET supports the Static Library feature across all of its editions.]