- See also Mike Stewart‘s Walkthrough: Creating a Visual FoxPro Application Setup Program Using InstallShield Express in VFP9 help or in the MSDN online.
- For some Ready-to-go Runtime Installers see wOOdy’s archive at Additional info about VFP 9.0 Versions
DLL Name | Register (order) | Default Location | Other Locations | Comment |
---|---|---|---|---|
msvcr71.dll | No (1) | App Folder | Microsoft Shared\VFP, WinSysDir | VC++ 7.1 Runtime library |
gdiplus.dll | No (1) | Microsoft Shared\VFP | App Folder, WinSysDir | GDI+ support |
vfp9r.dll | Yes (2) | –“– | –“– | STDLL and EXE support |
vfp9t.dll | Yes (2) | –“– | –“– | MTDLL support |
The runtimes for the language(s) you support: | ||||
vfp9renu.dll | No | The same as vfp9r.dll | The same as vfp9r.dll | English |
vfp9resn.dll | –“– | –“– | –“– | Spanish |
vfp9rdeu.dll | –“– | –“– | –“– | German |
vfp9rfra.dll | –“– | –“– | –“– | French |
vfp9rrus.dll | –“– | –“– | –“– | Russian |
vfp9rcsy.dll | –“– | –“– | –“– | Czech |
vfp9rkor.dll | –“– | –“– | –“– | Korean |
vfp9rchs.dll | –“– | –“– | –“– | Chinese (PRC) |
vfp9rcht.dll | –“– | –“– | –“– | Chinese (Taiwan) |
To provide compressed HTML help (CHM) within your apps: | ||||
foxhhelp9.exe | Yes | Microsoft Shared\VFP | WinSysDir | foxhhelp9.exe /regserver |
foxhhelpps9.dll | No | –“– | –“– | |
XMLTOCURSOR() function requires MSXML 3 : | ||||
msxml3.dll | Yes | WinSysDir | WinSysDir | |
msxml3r.dll | No | –“– | –“– | Required by msxml3.dll |
msxml3a.dll | –“– | –“– | –“– | –“– |
XMLAdapter class and HTML/XML Report output requires MSXML 4 : | ||||
msxml4.dll | Yes | WinSysDir | WinSysDir | |
msxml4r.dll | No | –“– | –“– | Required by msxml4.dll |
Object-assisted Reporting : | ||||
REPORTBUILDER.APP | No | App Folder | App Folder | Report Writer |
REPORTPREVIEW.APP | –“– | –“– | –“– | Report Preview |
REPORTOUTPUT.APP | –“– | –“– | –“– | Report Output |
Note for users of Inno Setup (and perhaps others): the ‘regserver’ flag only works for DLLs and OCXs. You will need to include “Filename: FOXHHELP9.EXE” with “Parameters: /REGSERVER” in the Run section.
MSXML 3 for XMLTOCURSOR() function
You also need MSXML 3 if you plan on using XMLTOCURSOR() function in VFP. Manually installing MSXML on Win 2k/XP/Server is a problem because you can’t overwrite MSXML in the SYSTEM directory without a reboot and copying the file to a special occasion. Hopefully whatever install mechanism you use can deal with this. For manual installs I suggest copying and registering the file only if it doesn’t exist already.
For situations where I started using XMLTOCURSOR or CURSORTOXML and the customer got an error, I’ve found that just the installation of the latest version of Internet Explorer will solve the problem. The client was usually running an older version of IE. Russell Campbell
GDIPLUS.DLL is only required for versions of Windows prior to 2000 (per Microsoft document entitled Visual Foxpro 9 – Application Distribution Process.
Also MSVCR71.DLL distribution is covered in Microsoft Article ID 326922. It says (in part)
“Because it is no longer a system component, install it in your applications Program Files directory with other application-specific code.”
However, when I configured my installer to place MSVCR71.DLL in the application directory, Visual Foxpro runtime could not find it. When I re-configured the installer to place the file in the Windows \ System 32 directory, Visual Foxpro found it ok. One more fubar for M$.
How did you configure Express as to where to put the msvcr71.dll? I can configure the MSM when VFP Runtime MSM is seleted because it is a dependency? If I tried to click the VC MSM first and configure it to install to systemfolder it seemed to let me. But, in all cases the file was deployed to the root of C:\ on my test machine?
Is it possible your problem was with the registration of the VFP9 runtime files and not with the running of the app itself? In my experience VFP9 apps runs fine with the MSVCR71.DLL installed in the app’s directory, as per the doc. However, MSVCR71.DLL must be present to register VFP9R.DLL, and registration fails if MSVCR71.DLL is present only in the app directory. To remedy this, configure your installer to install a temporary copy of MSVCR71.DLL to either the system folder (e.g., \WINDOWS\SYSTEM32) or the common files folder where the VFP runtime DLLs are located (\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\VFP), in addition to the permanent copy of MSVCR71.DLL you install to your app’s directory. Registration of the VFP9 runtime DLLs then succeeds, and you can remove the temporary copy of MSVCR71.DLL as part of your installation’s clean-up process. For an example of how to do this with Inno Setup, see the Inno Scripts topic. – Rick Borup
This was true for prior versions and it STILL is true for VFP9: You DON’T have to register the runtime DLLs as long as you put them in the same directory where your application is installed. And this also implies that Rick Borup’s way of dealing with MSVCR71.DLL is not necessary if that file too is installed in the same directory where your application is installed. Peter De Valença
However, this does not apply to FOXHHELP9.EXE or things like MSCOMCTL.OCX. You shouldn’t put them in your app folder because the user might delete your app folder without using the uninstall routine. If this happens, other applications that use those files won’t work.
See Also InstallShield Express And Vfp 9, VFP Runtime Compression,