What happened to me recently is a totally messed up notebook with two different version DLLs mixed in the ms shared/VFP system folder.
As that wasn't the only messed notebook for that client I had to create a setup which would clean up, uninstall a runtime installer package and install the correct version runtimes including msvcp71.dll for vfpcompression.fll. I learned to use msiexec for that matter, also for uninstalling, and found a tool called msm2msi by which I could turn the merge modules coming with VFP into msi setups.
All tht would not have been needed if the runtimes I distributed within the app folder weren't deleted, because then whatever mess was installed would not have been used anyway.
There's one most important thing to know:
In an EXE or DLL you have a stub routine which loads the main vfp runtime, in case of VFP9 either vfp9r.dll or vfp9t.dll as runtime for a multithreaded VFP COM DLL. The bad thing, inside the EXE or DLL you find VisualFoxproRuntime.9, not the more specific version number. But the opject code is for a certain version. What works most of the time is an EXE compiled in an earlier VFP9 version IDE can be run with the latest hotfix VFP9r.dll wothout a recmopilation. Because many opcode of object code don't change, what is fixed is the code in the runtime, and so you cn profit of bugfixes in runtimes without EXE recompilation and redistribution. But, and that is a big downer for this, I made very bad experences about this with SQLBUFFERING mode.
And what relates back to the original error, if the vfp9r.dll or vfp9t.dll is loaded by the EXE, DLL or MT DLL, then that runtime DLL loads the vfp9renu.dll (or other language) resource DLL and only accepts the exact same version a itself has, otherwise you get that resource file version mismatch. You have to be an obsessed perfectionist about this, if you want your final EXE or DLL o work on the target machine.
If you install one of the hotfixes, they automatically fix the main vfp9.exe of the IDE in the Home() folder, but other files like merge modules and runtime DLLs for the Ms Sahred system folder are merely extrated and you are instructed to move these files into system. If you don't follow these instructions you can easily run into this situation with a version mix in Home() and system folders for runtimes and merge modules. Then later creating setups on that wrong basis merge modules leads to further problems, only your customer will detect.
In my case that was only revealed after an update. Indeed an applilcation by me worked with a mix of 9.0.0.7423 vfp9r.dll and 9.0.0.5721 vfp9renu.dll(!) Which indeed shouldn't work according to what I said, after an update,which included all version 9.0.0.5815 version DLLs, just the vfp9renu.dll was upgraded to that version, while vfp9r.dll still remained as version 9.0.0.7423, and that, and only that lead to the version mismatch. So the update was indeed correctly packaged, it just was only upgradeing files newer and so that caused a problem.
Then also end users come to forums reporting their foxpro application doesn't work and put in some DLLs they are pointed to the fox wiki about runtime and don't understand half of it.
Ok, rant mode off.
In Windows Explorer you can add the file version attribute as a column of a detail/list display of files. That really is helpful to get an overview on what you have and if that all is the same version or not, and then you can fix that.
Bye, Olaf.
