Published on: Download Demo Source Code
Every programmer needs a collection of software tools and code to help making the projects development efficient, fast and secure. Central to these tools is the IDE (Integrated Devlopement Environment) that includes a code editor, a compiler, a debugger and other utilities that make life easier. But, also and perhaps more important, a collection of code snippets, classes, librairies, namespaces, data structures, ... to provide fast and tested solutions to solve common programming requirements during the course of applications development.
Often, these source codes are duplicated on different projects, where they are modified to fit new requirements, correct unnoticed bugs or add new features. This leads to different versions spread on the different projects and the mess when it comes to get the best out of the original code.
To avoid this situation to arise, the best approach is to share code across the different projects. This technique is very simple to implement and is described here.
So, what you'll achieve:
- Use classes and namespaces from a common source folder in multiple projects.
- Keep projects in sync with no file copies
- Changes in common code to the benefit of all projects sharing these files
For experienced programmers, there will be nothing new but I just hope it will be an interesting journey for those looking for better and easier code sharing.
A Word of Caution to Fellow Devs
The application is based on the MFC (Microsoft Foundation Classes) framework. I know that many people find MFC programming complex and quite outdated. But, since I don't bother writing software for other operating systems than Windows, I've kept this technology for all my programming projects. Since the Visual Studio compiler supports the latest ISO C++ 20 standard, STL is widely used as a replacement for classic C++ methods. In addition, Hungarian notation, introduced at Microsoft by Charles Simonyi, is systematically used to name program variables. Again, many programmers deny the use of this naming convention. But, once again, I don't worry about it. Charles Simonyi is one of the best software designers, and I have personally found Hungarian notation extremely useful in software development.
At TGMDev, the Development Environment is based on the latest version of Visual Studio Community 2026.
- Newest version of the IDE: this new release with improved performance, build times, projects loading, and overall responsiveness.
- AI-powered assistance: although it's not absolutely required for this simple project, this version includes built-in AI features for code completion, explanations, and suggestions.
- Modern Interface: VS 2026 comes with a refreshed design and updated icons.
- Side-by-side installation: this new release can be installed alongside VS 2022 and can import automatically VS 2022 project (with upgrade of the platform toolset from v143 to v145)
- Free for eligible users: the Community edition is a free IDE for individual developers, students and open-source contributors.
This technique applies also to previous versions of Visual Studio but I always prefer to stick with the latest one. So the code was built with Visual Studio 2026 ...
All developpers have a different way and different logic to organize projects and codes. For the purpose of this paper, the following code organization will be used:
The master root directory is named 'TGMDev'.It contains three subdirectories: Projects, Common and Samples.Hover to enlarge view The directory 'Projects' contains the different C++ projects. Amongst them, the project 'Demo_ExtStatic' is the heart of this paper.
Hover to enlarge view The directory 'Common' contains the different classes, namespaces and librairies that are shared betweeen C++ projects. Amongst them, the directory ExtCtrl contains the .cpp and .hp of the class that willl be added to the project Demo_ExtStatic.
Hover to enlarge view
The creation of the project 'Demo_ExtStatix' is straightforward:
- Select the project template 'MPF App'
Hover to enlarge view - Enter the project name, location and solution name
Hover to enlarge view - Select the application type 'Dialog based'
Hover to enlarge view - Keep the remaining options according to your way of working. For this app, I removed all advanced options.
The configuration is quite standard for a 64-bit applications:
- Latest Plateform Toolset (v145)
- C++ Language Standard: ISO C++ 20
- Use MFC in a Static Library, to get rid of some DLLs potential issues
- Character Set: Use Unicode Character Set
Visual Studio uses a lot of macros, with the synthax $(name), that act as variables that help manage build settings, paths, and configurations, making project settings portable and reusable across different machines and Visual Studio versions. Macros are used to specify paths and directories, build configuration, user-defined values, ..
Sharing classes across projets requires a minimal knowledge of the macros and, specifically two important ones: $(SolutionDir) and $(ProjectDir)
- $(SolutionDir): this macro represents the absolute path to the directory where your solution file (.sln or .slnx for Visual Studio 2026) is located. This path is the commonplace for all projects within the same solution.
In the example of the Demo, this macro expands to: C:\TGMDev\Projects\ - $(ProjectDir): this macro represents the absolute path to the directory where the individual project files are located. In a solution with multiple projects, $(SolutionDir) will point to the common parent folder, while each $(ProjectDir) will point to its respective subfolder.
In the example of the Demo, with only one project, this macro expands to: C:\TGMDev\Projects\Demo_ExtStatic\Demo_ExtStatic\
This illustrates the importance of the apparently banal setting exposed during the early stage of the project creation:
Checking the box 'Place solution and project in the same directory' disables the edit box 'Solution name'. This leads to a project where the file Demo_ExtStatic.sln and Demo_ExtStatic.vcxproj are located in the same directory and the macro $(SolutionDir) is equal to the macro $(ProjectDir). Note that the file .sln is changed to .slnx when using Visual Studio 2026.
Reaching the macros of a project is not the simplest or most obvious method:
note: different other settings can be used to reach the macros...
- Add, to the project, the actual implementation of the class (the .cpp file) as an existing item
- Include the declaration file of the class (.h file) in the list of the additional include directories reachable by the Project
1. Include Declaration file to the additional directories of the project
- Select the menu 'Project | Properties'
- Select the item 'Configuration Properties | C/C++ | General'
- Select the item 'Additional Include Directories'
- Add the following text: $(SolutionDir)..\..\Common\ExtCtrl\
- Click on 'Apply' and confirm with 'Ok'
2. Add Existing Implementation file to the project
- Select the 'Solution Explorer' in the the left Tab of Visual Studio
- Right-click the project item (here Demo_ExtStatic)
- Select the menu 'Add | Existing Item ...'
- Select the shared implementation file (here extstatic.cpp in the common directory)
- Confirm by clicking the "Add' button
- Let Visual Studio performs the required changes in the project configuration
Basically, it's finished !!! Two steps and all is done. So now, let's try it...
Ooops !!! Compilation error occurs !!!
Yes. The pch.h file is NOT included in the implementation file of the shared class. Instead, the following line is included in the declaration file:
#include "afxwin.h"
Why is that ? Because the file pch.h est not accessible for the common file. And for a good reason: there is no pch.h file in the common directory.
The solution is to modify the configuration of the shared .cpp file itself and remove the use of precompile headers.
- Right-click the common file (here extstatic.cpp) in the 'Solution Explorer'
- Select the menu 'Properties'
- Select the item 'Configuration Properties | C/C++ | Precompiled Headers'
- Select the option 'Not Using Precompiled Headers'
So, now, compilation does not generate any error. And, each project that use that shared class will compile the same physical .cpp file. And, moreover, each time the shared file is modified, the changes will benefit to all projects.
Basically, it's finished !!! Three steps and all is done.
3. The demo: Add CExtStatic to Dialog Window
The remaining things to do are the steps of a standard MFC development: adding controls to the dialog, adding variables and configuring the controls.1. Adding the controls to the dialog
2. Adding the variables
3. Configurating the controls
And the result is ....
Hover to enlarge view
Remember that the macros $(SolutionDir) and $(ProjectDir) are terminated by a \ character.
The correct additional directories are easy to find when using the logic explained here behind:
From $(SolutionDir) to C:\TGMDev\common\ExtCtrl\:
- $(SolutionDir) expands to C:\TGMDev\Projects\Demo_ExtStatic\
- $(SolutionDir)..\ expands to C:\TGMDev\Projects\
- $(SolutionDir)..\..\ expands to C:\TGMDev\
- $(SolutionDir)..\..\Common\ExtCtrl\ expands to C:\TGMDev\Common\ExtCtrl\
From $(ProjectDir), you’d need one more ..\ if you do not check the box 'Place solution and project in the same directory' in project creation - $(ProjectDir)..\..\..\Common\ExtCtrl\ expands to C:\TGMDev\Common\ExtCtrl\
How to verify (no guesswork)
- In the same property page, click the “Macros…” button to see the actual expanded value of $(SolutionDir)/$(ProjectDir).
- Temporarily enable /showIncludes (C/C++ → Advanced → “Show Includes”) and build once. The complete #include shared file path will be displayed.
- In the editor, right-click #include "ExtStatic.h" and select the item "Open Document". If it opens from the common folder, you’re good.
Sharing classes and namespaces is a very powerful method to reuse existing tested and validated code without the need to copy the files to each project. It means a smarter handling of your standard code and a very easy way to spread any changes to every project automatically, avoiding potential mess generated by different versions of the same code.
Feel free to add comments or questions about DebugTrace...


















