VS2010 How to reduce the compilation file size (statically linked MFC)

since VS2005 upgraded to VS2010, the build out of the file (EXE, DLL) on the inexplicable increase of a lot, MSDN blog has a blog, detailing the size of the reasons for the increase, as well as the method of reduction. The reason for this is that size increases because of the introduction of Dlginit. He allows the addition of MFC controls on dialog. This function, during the static link, introduces a number of function that may not be required, because it is not possible to predict the need for these function during the build process.
Workaround: 1, add the following macro definition in "stdafx.h" #define _afx_no_mfc_controls_in_dialogs 2, CDialog the parent class needs to have CDialogEx modified to CDialog 3, Initinstan Ce to prohibit the creation of CShellManager, that is, the need to Cmfcvisualmanager::setdefaultmanager (Runtime_class (cmfcvisualmanagerwindows));

Comment out.

Through macro-defined methods to link different Lib, different Lib difference is whether the dialog support MFC control. The cost is that MFC control cannot be used on the dialog.

Zz:http://blogs.msdn.com/b/vcblog/archive/2012/02/06/10263387.aspx
reducing the Size of statically-linked MFC applications in VC11

Hello, I ' m Pat Brenner, a developer on the Visual C + + libraries team, and I am the primary developer working on T He Microsoft Foundation Classes (MFC).

In Visual Studio, the size of statically-linked MFC applications grew substantially. We ' ve gotten a number of comments about this issue, so I wanted to post a article about the cause and solution that W E have come up with. cause

In Visual Studio, we added a feature to the resource editor which allows to add MFC controls to your. The MFC control types appear in the toolbox along with the standard Windows controls. Properties specific to the MFC controls can being set on them and so they behave as desired when the dialog is created.

In work properly, a dlginit blocks has to is written in the RC file for the project, which contains the P roperties information in binary format. The Dlginit block has to being parsed when the dialog are being initialized, so the controls can be initialized using the info Rmation in the Dlginit block. The code to does this parsing lives in Cwnd::executedlginit.executedlginit method lives in Wincore. CPP, whose object is always included in every statically-linked MFC application (because it contains the CWnd constructors and the AfxWndProc method).

The code that performs the MFC control initialization, of course, needs to know about all of the MFC controls. Those controls, in turn, could need to know about various visual managers into order to know the how to draw themselves. And the visual managers, in turn, have dependencies on other MFC classes.

The result of this dependencies is so much about MFC needs to being pulled into a statically-linked MFC application, BEC Ause the linker cannot determine at build time that none of those methods would need to be called, since it all depends on The content of the RC file and dlginit structures inside it.

We were alerted to this size increase in statically-linked MFC applications shortly before the release of Visual Studio 20 RTM, but we were not able to definitively establish the cause before Visual Studio shipped. Even if we had, we most likely would not have been able to put the finishing touches on a solution before the release date , because we had to try several different approaches before arriving in a working solution that puts a very small ENT on the MFC developer. Solution

To fix the problem, we eliminated a number of dependencies between MFC classes (further details are below). We also moved several methods that have a effect on the MFC control Initialization:cwnd::executedlginit, DDX_Control, Af Xregistermfcctrlclasses cmfccontrolcontainer::subclassdlgcontrols Andcmfccontrolcontainer::P Reunsubclasscontrol

into separate source modules.

These separate source modules are then compiled, two different ways:with-not #defined They are built into the standard static MFC libraries, Nafxcw[d]. LIB and Uafxcw[d]. LIB, with the standard behavior enabled. With the _afx_no_mfc_controls_in_dialogs #defined, they are built into a new small static MFC library, Afxnmcd[d]. LIB, without the ability to initialize MFC controls on dialogs. (The NMCD in the library name is a acronym for "No MFC Controls on Dialogs".)

The new smaller library has the same methods (same names, but different implementations) as the larger standard MFC Li Braries, so we must make sure to link it in the. This is ensures that's functions that don ' t have any dependency on MFC control initialization are used and the dependencies are eliminated. This is accomplished via symbols which are defined in the new source modules, and force-included via  #pragma  stat Ements in AFX. H based on  #defines set.

The result ' of this work is ' you can simply  #define _afx_no_mfc_controls_in_dialogs in your MFC Applicati On ' Sstdafx.h file, and all the code this performs MFC control initialization on dialogs'll be left out of your APPL Ication. In a simple dialog-based application, this would reduce the size of the application by approximately 80%. [Note this if You do use MFC controls on a dialog, and build with _afx_no_mfc_controls_in_dialogs  #de Fined, your application may isn't run at all (or dialogs'll not appear) because a dialog containing a nonexistent window C Lass cannot be created. We added trace statements to MFC to this effect to help point out this issue.]

In addition, we have made changes in the code generated by the MFC Application Wizard. It'll generate code that contains#ifdefs for The _afx_no_mfc_controls_in_dialogs, so:dialogs'll be derived from& nbsp Cdialog instead of cdialogex if the  #define  IS set. No cshellmanager will be created in the application ' S initinstance method if the  #define  is set.

We have implemented these changes in MFC for the next major release of Visual Studio. Now so we understand the cause and the best solution, we looked at the possibility of porting the changes back to Visual Studio in order to benefit applications built and that version. Unfortunately, the changes we made to reduce the dependencies between MFC classes included:moving d2d-related member Func Tions/data out of the _afx_global_data class to a separate class adding a new virtual method to both CMDIChildWnd and Cmdi Childwndex Adding a new to the CWINAPP class

Because these changes introduce binary incompatibilities, we are don't able to port the changes back to Visual Studio W Ithout breaking existing MFC applications.

I Hope you find this information helpful!

Pat brenner 
Visual C + + libraries Development