Visual C++ :: Deployment (install) Project Built Fails To Replace DLLs

I have a few VC2008 projects whose solutions also includes deployment projects, in which the primary output of several DLLs are included along with the primary apps EXE file. These DLLs are all part of the solution. Now because of the way I do my DLLs, which for lack of better phrase I'll call a true DYNAMIC link (the .LIB file can be discarded), and because I'm careful to ensure full backward compatibility in any new DLL versions, I would like to tell my deployment project to ALWAYS replace existing DLLS with the new versions, or at least offer a choice if it shouldn't be done unconditionally. Unfortunately it never seems to do that!

I'm being careful to create new overall project versions within the deployment project itself, as well as keeping my version resources, attached to each DLL up to date, and always do a full rebuild of everything in the solution (including the DLLs) prior to building the deployment project. But time and again the old DLLs stay un-updated after the install, and the person running it would have no way to know that without examining the target directories and examining file dates and/or versions. A customer shouldn't have to go through all that. I've gotten into the habit of instructing installers to fully un-install old versions before installing a new one, but as you probably know uninstalling from the control panel won't remove shared DLLs.

I was starting to think maybe the latest DLLs weren't being included in the deployment project at all. But if I manually delete those DLLS and do the install, the latest greatest are then always placed.

If I can't find a setting in the deployment project to change this behavior, I'll have to write a separate little console app to force delete (or at least archive) all the relevant DLLs as a pre-installation step. Or maybe supply a BATCH file to do all that, and run the install last. But it seems like a reasonable thing that a setting to make a deployment (MSI) file unconditionally overwrite DLLS, whose version or creation date is newer, ought to be an obvious feature. But if such an option exists, I've missed it completely.