Use of MFC: MFC in Shared DLL and MFC in Static Libraries

Foreword
When we use Microsoft Visual Studio software (that is, we often say VS), one of the project properties is called "MFC use", which contains different settings, which will affect the use of the programs we write. Today I Just encountered this situation, let's summarize together to avoid making the same mistake.

Content
Yesterday I wrote a small program that uses an MFC application project. The version of the tool is VS2013. The project parameters are default. One of the settings is called "Use of MFC." The default setting is "Use MFC in a shared DLL." Although I saw it, I did n’t take it to heart. During the encoding, I solved the problem of an MFC using a multi-byte character set to report an error. I wo n’t expand it here, and I will list it later. It ’s perfect! Handed it over to a user called "Little Lightning", and then she got the company computer with great excitement and used it, but it was wrong! !! !!
"This program cannot be started because mfc120.dll is missing from the computer. Try to reinstall the program to solve this problem." The first thing I thought of when I saw this problem was the dynamic link library, because I was using VS2013. It is a 12.0 version of the library file, so it should be that the target machine does not have this library. Of course, you can manually download this library file and add it to the "C: \ Windows \ System32" directory, but in the program development project, you cannot ask all users Will do this, and can only find a solution from themselves.

Of course, I also carefully checked this parameter called "Use of MFC", which actually includes 3 options:

1: use standard Windows library
2: use MFC in shared DLL

3: using MFC in a static library

These three certainly have different meanings:

The first, as the name implies, uses the Windows SDK API library instead of the MFC classes. What is the situation that an MFC application does not use MFC classes? At first, I couldn't figure it out. Later, I created a new MFC application project, and then filled this parameter into this one. Then the program failed to compile. As shown in the figure below, this illustrates the problem. If it is an MFC project, you must choose the second or third item, and the first item "Use the standard Windows library" is prepared for non-MFC projects.

The second refers to the fact that the contents of some MFC DLLs are not included in the EXE file at the time of packaging, so the EXE file is small, but the runtime requires the relevant DLL file in the system. This is the option I chose at the beginning of the program, which requires the target computer to include at least the "mfc120.dll" library file, otherwise it cannot be used.

The third is to write the relevant code in the DLL into the EXE file. The file is large, but it can be run on a machine without the relevant DLL. I personally feel that using this option during program testing should be better, at least to ensure the normal operation of the program.

To sum up

• For the MFC application project, regarding the "use of MFC" property, you should choose "use MFC in shared DLL" or "use MFC in static library".
• The "Use standard Windows library" option can only be used in non-MFC projects. If it is used in MFC projects, it will cause code compilation errors.
• The program executable file generated by the "Use MFC in shared DLL" option is relatively small, but requires the target machine to have the necessary library files installed.
• The program executable file generated by the "Use MFC in static library" option can be executed by almost all Windows, but the program is larger and contains necessary library files, which can basically guarantee normal operation on other machines.