Messages
Reply
Edit
Delete09:00 pm
3RK1918TK
| From: | Rick Strahl |
| To: | Andrew Hall |
Just copy the actual runtime files not the merge module... The Fox Wiki has info on exactly what files you need.
+++ Rick ---
Thanks Rick & Doug
Copying the runtime files from their default location in ..\Microsoft Shared\VFP to the application folder did indeed cause the application to work. Only one minor problem: while I can set the location of the VFP Runtime Libraries (and C Runtime Library) to InstallDir or the application folder Name within Install Shield they still end up in their default locations as above, so a manual copy or run of a batch file is required to make the file transfers. Do you happen to know if there is any way of persuading Install Shield Express for VFP to behave as requested?
Just one other thought. If Run as Administrator works while Run as Standard User doesn't when run afterwards, could that still be caused by registration of components failing? Surely registration takes place at Setup?
Again, thanks and best regards,
Andrew Hall
In that case do what Doug suggests: Put the runtime files in your application folder rather than in the shared location. I think the problem is that the registration of components might be failing.
Make sure that your install file is an .msi file or has Setup as part of the EXE file name to force Windows to automatically elevate permissions to administrator when installing too.
+++ Rick ---
Hi Doug
Thanks for the suggestions and I appreciate your interest. My problem is that I have six different versions of the application, each of which is reasonably complex within Install Shield Express - hundreds of files distributing to tens of different target computer locations, which I guess would take a few weeks to rewrite as scripts within Inno (I've only played around with it for a couple of hours). I am fairly sure the problem lies with the method of registration of the runtime files since the application works when Run as Administrator is used; while Inno Setup may be the better long-term way forward I'd like to find a quicker solution in the short term. I'd have thought this was a generic problem for many VFP developers as Windows 64 bit systems increase their market share.
Regards,
Andrew Hall
Hi Andrew.
I am using InstallShield Express provided with VFP9 as the installer for my application. The resultant files after installation of my app on a Windows7-64 bit machine in Program Files (x86)\common files\microsoft shared\VFP are (Foxhhelp files,Report??.app files+) VFP9r.dll, VFP9RENU.dll, VFP9t.dll,MSVCR71.dll (the last of which I added within InstallShield and is also present in the Program Files (x86) application directory).
A couple of suggestions:
- Use Inno Setup. It's a free, fast, easy-to-use installer than many VFP developers use. Unlike the version of InstallShield that comes with VFP 9, Inno knows all about modern systems, including 64-bit Windows 7.
- Put the VFP runtimes in the application folder. That eliminates several problems, including possible interaction between different versions of VFP installed by multiple applications (which isn't an issue if yours is the only VFP application on the system).
I've been doing this for years and have yet to run into installer or UAC-related issues.
Doug
West Wind Technologies
Making waves on the Web
