tags:

views:

39

answers:

2

Is it possible to recompile an MFC DLL while its "client" executable is running, and have the executable detect and pick up the new changes? If it's possible, is it foolish? Being able to recompile the DLL without restarting the exe would save some time in my coding workflow. I am using Visual Studio 2008, code is written in native C++/MFC. My code changes are entirely contained in the DLL, not the EXE.

Thanks!

+2  A: 

Unfortunately, unless the executable has support for hot-swapping DLLs, you can't do it. The standard DLL loading mechanism in Windows will load it either at the start of the process or at first use of a function exported by the DLL and will not watch the file for changes in order to reload it. Also, depending on how the DLL is loaded, the file might be locked for changes.

You will have to stop your client executable before recompiling.

Franci Penov
Yeah, as I suspected the "dynamic" in DLL was too good to be true...
phipster
"dynamic" in DLL is to indicate that the relevant code is loaded at run time as opposed to static linking at compile time. It does not mean "reloading on-the-fly". There are quite a few issues with hot-swapping DLLs the way you want it, including quite big security and stability problems. (just imagine a malicious web page finding a browser issue to download a dll somewhere in the path and all local processes automatically reloading it immediately :-))
Franci Penov
A: 

Yes, it's possible. You'll need to make sure the executable explicitly loads your DLL (via LoadLibrary). If your executable implicitly loads your DLL you'll have the issues that Franci described.

To update the library while the executable is running:

  • Define some convention for staging the new version of the DLL. It could be in a separate folder, or with a different file name/extension.
  • Have a means of checking for a new version of the DLL. This could be in response to some specific gesture in the user interface, or you could monitor the directory for changes from a background thread.
  • When you see a new version, unload the old version (FreeLibrary), then delete it and move the new version to the desired location and reload it (LoadLibrary).

If your DLL implements any COM objects, let me know and I'll give you some additional tips.

Jim Lamb
Hey, great tip, Jim! Unfortunately it appears the DLLs are loaded implicitly - the codebase, developed over nearly 10 years, is now up to 2 million+ SLOC, comprising several dozen DLLs and EXEs. I doubt I could persuade management to allow such a change for this lowly codemonkey's convenience :)
phipster
Unfortunately, it's not sufficient. The new DLL may have its functions at different addresses. This means additionally that you would have to call `GetProcAddress` for all functions you need, after each `LoadLibrary` call. And since it's an MFC DLL, you typically don't control that.
MSalters
@MSalters, true - another reason not to use MFC. Straight-up COM is usually a much better solution for this kind of problem.
Jim Lamb