Regular DLL using: MFC Shared vs MFC statically linked

Question

When we create a DLL using Visual studio (VC8 or 9), we get an option as create Regular DLL

 using MFC as shared DLL

or

 using MFC as static library

How are they different? Which one is advisable to use?

Answer 1

A static library means the code you use from the library is included in your executable. Because of this, you don't need to ship the library or require the end user to have it on their machine. However this bloats the size of your executable and ties you to that library version, so if you need to update just the library, you have to ship a new executable.

A shared library calls the library at the time it needs it (runtime) to execute the code, but it requires the user to have it (usually a specific or minimum version) installed on their machine. You can also distribute the required version of the library with your application if you need to.

As for which is better, I don't know. I'm not a Windows C++ or MFC programmer so I couldn't say. On my Linux servers, the applications I write are generally server-side and thus use shared libraries.

It depends on how your application is to be used, distributed, updated, how often the MFC library changes, if it's generally available on user's PCs etc.

Answer 2

[I think I got my answer now]

If you use MFC DLL as dynamic linking, your code will need the Microsoft Foundation Library DLL's (specifically the version your code requires) installed along with your application or dll in the user end. So this means your installation package would contain

• Your application/DLL and supporting files
• All MFC Dlls

This makes the installation package size go bigger and also make take time for user to download your installation setup.

If you link to MFC as static library, you code will work even without MFC DLLs present at the user end . The reason being pretty simple that all the MFC libraries you refererred in your code, will be linked into your application or dll. This means those MFC libraries used in your app/dll becomes the part of the your binary; however, your app/dll will be little bigger.