Getting ready for delivery


Before you can package up the Installation, you need to make sure you have all the components ready to ship.

Executable components

The executable components need to be built. There are many options available that need careful consideration. Naturally, a decision about deploying an APP, EXE, or DLL is made long before you are preparing to build the executable for an immediate deployment. This decision should be made during the design phase of the application development cycle.

One thing to consider is what you want to do for your final build for the release. We strongly advise selecting the Recompile All Files and Display Errors options found on the Build Options dialog (see Figure 1 ). The reason for this is plain and simple. It is possible compiler-flagged errors will not show up in the current build even though they exist in the source code. How? If you edit the code and do a build, the build displays the errors if you select it to do so. If you do not edit the code the errors exist in and do a rebuild, the errors do not display (even if you select the Display Errors option) because the code was not changed and Visual FoxPro only rebuilds code that needs to be recompiled. Because the code was compiled and not edited, the last recompile time is after the last edit time and Visual FoxPro skips it during a build.


Figure 1. The Build Options Dialog is critical to determine the contents of the executable you are going to deploy.

This is why it is important to check these two options when building an executable you intend to install for the customer to test or use in production.

The Project Information dialog (see Figure 2 ) is equally important to review before making a final build for the customer. The Debug Info option determines whether or not the source code is included in your compiled application. The source code is nice to have when errors are recorded because Visual FoxPro needs the source code to display the source line with the error and track the line number where the error occurs. However, it also makes it easier for someone to use a product like ReFox to decompile the source code. The Encrypted option does not stop products like ReFox from decompiling your applications, so we do not bother using this option (see Chapter 10, ‚“Security ‚½ for more details). Using this option can reduce the ability to compress the executables, which leads to longer file transfers and downloads on the Internet.


Figure 2. Selecting the Debug Info bloats your executables by including the source code for the application into the EXE file.

The Icon command button allows you to select a custom icon ( Figure 3 ) to embed into the executables (not APP files). This icon should be an ICO file with 16x16, 32x32, and 32x32 with 256K color (if deployed on Windows XP) pixel icons. This icon is the icon that shows up in Windows Explorer. Visual FoxPro 8 was the first version to start supporting the 32x32 with 256K color icons.


Figure 3. Selecting the icon on the Project Information page determines the icon that displays in Windows Explorer.

Help

Implementing a Help file seems to be the part of development the majority of developers avoid. Help can come in the form of user documentation (book style from a word processor) and/or online (Windows based HTML). A bug fix release may only need an update to the documentation, while new development may require all new help to be written. We find our clients avoid the cost of creating and implementing Help because they are seriously involved in the development of the application. We also know many custom applications never see Help because they are developed for a small user base already familiar with the business at hand.

If Help is implemented you need to make sure you include the necessary Help subsystem files so your Visual FoxPro applications can interact with the Help files. See the sections on ‚“Visual FoxPro runtimes and dependencies ‚½ and ‚“Help and documentation file ‚½ for details.

Data conversion

Update releases are common with custom software, in fact we always encourage our customers to add new functionality and make changes to existing functionality in their application because it means more business for us. Changes to the applications often require the database to change. New applications might be replacing a legacy application and we need to convert the data from the old data stores to the new database. If there is no legacy system to convert data you may still need to initialize a new database for the first use.

Updating existing VFP data is simple if you own a copy of Stonefield Database Toolkit (SDT). We have successfully used the SDT Update method for years to handle the structure changes. There simply is no single third-party tool as important to a Visual FoxPro developer as SDT if you use VFP data, and this is the biggest reason to buy it. However, there are still cases when the new structures need to be populated or data converted from different fields or from different tables.

Updating a backend SQL database is not as easy because there is no SDT for SQL Server, Oracle, MySQL, etc. You need a mechanism to run update scripts in the database. If you have a sophisticated customer with an on-site database administrator you might be able to just send a script file for the administrator to run. You might have access to the server and be able to run the script yourself. You might have to create a program that executes the necessary scripts programmatically. The scripts need to be run in a specific order and it might be a situation where you have to run some of the scripts, convert some data, and then run some other scripts.

The conversion of data from the legacy system can present numerous challenges. Data clean up and scrubbing, proprietary formats, lack of referential integrity, values outside of valid ranges or values that break new field level rules, and missing or corrupt fields are just some of the problems you face. Creating a test set that covers each and every case or situation can be difficult.

A new database can be implemented in many ways. Visual FoxPro data (with empty/ initialized tables) can be copied to a customer ‚ s folder. You can also use the utility called GenDBC that ships with Visual FoxPro to generate a program with code necessary to create the database container, the empty tables, indexes, views, relations, and connections. SQL backend databases backups can be restored or scripts can be run to generate the necessary database objects.

Regardless of the data conversion needs, these conversion routines need to be developed and tested. They need to be tested often because data changes can happen at any time during the development phase. We cannot stress enough the need to test the conversions with real data. Work with your clients to get a recent copy of their production data to use in this test. Make sure to perform one final test of the conversion before delivering the installation.

Visual FoxPro runtimes and dependencies

Applications updated and released after a Visual FoxPro version upgrade require all the runtime files ship with your application. The service packs can include updated runtime files that need to be released with the updates to your custom applications.

It is very important to keep the runtimes in sync with the development version of Visual FoxPro. One example of a problem could be delivering an application using edit boxes with the original Visual FoxPro 7 runtimes. Microsoft released a hot fix for the runtimes soon after the release of Visual FoxPro 7. If you do not update the runtimes at customer sites, they will not have scrollbars in the edit boxes on their forms. This was corrected in the hot fix (and included in Service Pack 1).

So what files do you need to distribute? There are a few directories to check for new runtime files. Your directories could be different depending on the operating system and the directory structure where you installed Visual FoxPro. For Visual FoxPro 7 you have the following files:

  • C:\Program Files\Common Files\Microsoft Shared\VFP\ contains the VFP7R.DLL, VFP7T.DLL, VFP7RCHS.DLL, VFP7RCHT.DLL, VFP7RCSY.DLL, VFP7RDEU.DLL, VFP7RENU.DLL, VFP7RESN.DLL, VFP7RFRA.DLL, VFP7RKOR.DLL, VFP7RRUS.DLL, VFP7RUN.EXE, FOXHHELP7.EXE, and FOXHHELPPS7.DLL.

  • C:\Program Files\Common Files\System\Ole DB\ contains the VFPOLEDB.DLL (VFP 8 overrides the same named file as the one installed with VFP 7)

  • C:\Program Files\Common Files\Microsoft Shared\Merge Modules\ contains the merge modules used by InstallShield Express and other install tools that leverage the Windows Installer technology. These files include VFP7RCHS.MSM, VFP7RCHT.MSM, VFP7RCSY.MSM, VFP7RDEU.MSM, VFP7RESN.MSM, VFP7RFRA.MSM, VFP7RKOR.MSM, VFP7RRUS.MSM, VFP7RUNTIME.MSM,VFPACTIVEDOC.MSM, VFPHTMLHELP.MSM, VFPODBC.MSM, and VFPOLEDB.MSM. The merge modules are not directly distributed to the customers, but are used by install tools like InstallShield Express and Wise for Windows Installer.

For Visual FoxPro 8 you have the following files:

  • C:\Program Files\Common Files\Microsoft Shared\VFP\ contains the VFP8R.DLL, VFP8T.DLL, VFP8RCHS.DLL, VFP8RCHT.DLL, VFP8RCSY.DLL, VFP8RDEU.DLL, VFP8RENU.DLL, VFP8RESN.DLL, VFP8RFRA.DLL, VFP8RKOR.DLL, VFP8RRUS.DLL, FOXHHELP8.EXE, FOXHHELPPS8.DLL, AND GDIPLUS.DLL.

  • C:\Program Files\Common Files\System\Ole DB\ contains the VFPOLEDB.DLL (VFP 8 overrides the same named file as the one installed with VFP 7)

  • C:\Program Files\Common Files\Merge Modules\ contains the merge modules used by InstallShield Express and other install tools that leverage the Windows Installer technology. These files include VFP8RCHS.MSM, VFP8RCHT.MSM, VFP8RCSY.MSM, VFP8RDEU.MSM, VFP8RESN.MSM, VFP8RFRA.MSM, VFP8RKOR.MSM,
    VFP8RRUS.MSM, VFP8RUNTIME.MSM, VFP8HTMLHELP.MSM, VFPOLEDB.MSM, and VFP_GDIPLUS.MSM. The merge modules are not directly distributed to the customers.

You absolutely need to release at least two runtime files along with your executable (EXE, DLL). The primary runtime DLLs are the VFP8R.DLL (or VFP7R.DLL, VFP6R.DLL) and one of the VFP8RXXX.DLL (VFP7RXXX.DLL, VFP6RXXX.DLL) language resource file, where the xxx is three letters that specify the selected language. If you are releasing a component that needs the multi-threaded runtimes then you need the VFP8T.DLL (VFP7T.DLL, VFP6T.DLL) and the language resource file. The rest of the runtime files are optional.

You might have noticed the VFP8RUN.EXE and VFPACTIVEDOC.msm are missing from the list. The ActiveDoc class still exists in VFP for backward compatibility, but Microsoft removed the functionality in Visual FoxPro 8 because of security reasons.

Visual FoxPro 7 introduced a new dependency for runtimes, the Microsoft Visual C++ 7.0 Runtime DLL (MSVCR70.DLL). This file is found in a merge module called MSVCR70.MSM, located in the C:\Program Files\Common Files\Microsoft Shared\Merge Modules\ folder. The same dependency is necessary for Visual FoxPro 8.

Visual FoxPro 8 introduced a new dependency for the runtimes, the Microsoft Graphics Device Interface Plus (GDI+) runtime DLL. This file is found in the VFP_GDIPLUS.MSM

merge module, located in the C:\Program Files\Common Files\Merge Modules\ folder. The GDIPLUS.DLL file must be registered before the VFP8R.DLL if you are manually installing them or using an installer package that is not using Windows Installer Merge Modules.

If you are using the CursorToXML() or XMLToCursor() function you need to include the Microsoft XML Parser (MSXML3.DLL, MSXML3R.DLL, MSXML3A.DLL) to the Windows System folder. These files are found in the MSXML3.MSM merge module, located in the C:\Program Files\Common Files\Merge Modules\ folder. We strongly recommend using the merge module because it works around the issues of installing a set of files that are likely to be in use. Installing the new files requires a reboot of the computer.

If you are using the new XMLAdapter class introduced in Visual FoxPro 8 you need to include the Microsoft XML Parser 4 DLL files. These files are found in the MSXML4.MSM merge module, located in the C:\Program Files\Common Files\Merge Modules\ folder. We strongly recommend using the merge module because it works around the issues of installing a set of files that are likely to be in use. Installing the new files requires a reboot of the computer.

If you are creating an application that accesses a Web service you need to include the SOAP SDK Files (SOAP_CORE.MSM) found in the C:\Program Files\Common Files\Merge Modules\ folder, the Visual Basic Virtual Machine (MSVBVM60.MSM), Microsoft Component Category Manager Library (COMCAT.MSM), and the Microsoft OLE 2.40 (OLEAUT32.MSM). The last three merge modules can be downloaded from the InstallShield Express Merge Module download page. You go to the InstallShield Express support page and select the Merge Module link.

If you are creating an application for release on a Middle Eastern operating system, be sure to add VBAME.DLL file to your installation package and have it installed in the Windows System folder.

Microsoft released a new version of the Visual FoxPro OLE DB driver in August 2003 and again with Visual FoxPro 8 Service Pack 1. This driver supercedes the one released with original release of Visual FoxPro 8 and Visual FoxPro 7. It is Microsoft ‚ s recommendation to use this new driver over any of the drivers previously released no matter what version of Visual FoxPro you developed your solution in. If you need to have both loaded on the same machine, you need to rename the older DLL because the file names are identical. Here are the instructions provided by Microsoft:

  1. Shut down any applications that might be using the provider, such as IIS, or any desktop applications that use the provider.

  2. Open the ...\Program Files\Common Files\System\Ole DB folder

  3. Right-click vfpoledb.dll, select Rename, and then change the name to vfpoledb_save.dll.

  4. To restore the saved version, delete or rename this release version and rename vfpoledb_save.dll to vfpoledb.dll. It should not be necessary to re-register the provider, provided you did not uninstall the previous version.

    On The Web ‚  

    The latest version of the Visual FoxPro OLE DB driver can be downloaded from the Microsoft download Web site:
    http://microsoft.com/downloads/details.aspx?FamilyId=0F43EB58-7A94-4AE1-A59E-965869CB3BC9&displaylang=en and is included with Visual FoxPro 8 Service Pack 1.

The Visual FoxPro 6 Setup Wizard placed the runtimes in the Windows System or Windows System32 folder. This was common practice and is an old standard. Newer operating systems attempt to clean up the situation referred to by the development community and recognized by Microsoft as ‚“DLL Hell. ‚½ The new location for the runtimes as they are installed by the merge modules is the C:\Program Files\Common Files\Microsoft Shared\VFP\ folder. You can still place the Visual FoxPro runtimes in the Windows System folder and your custom applications will find the runtimes just fine, but your application will not be following the new standards. We recommend following the new standards to avoid problems.

One of the problems with loading the runtimes to a single folder can occur when you have multiple applications developed with the same major version of Visual FoxPro. There are five service packs (SP) deployed for Visual Studio 6, four of which included new runtimes for VFP. If you developed and system tested one of your applications with VFP 6 SP3 and another with VFP 6 SP5 and installed the runtimes to the same folder, you would have only one set of runtimes (the ones from SP5). If Microsoft changed the behavior of a feature between the two service packs and you did not have time to test the application developed under SP3, your clients could find a problem with your application. The recommendation in this case (if you cannot perform the testing of the older app) is to include the runtimes in the same folder as the executable or in a special folder and pass the ‚ D parameter to the executable to specify which set of runtimes are used. If you use this mechanism/setup, you will not be able to use the merge modules to install the runtimes. You need to deliver the runtime files individually and directly specify the folder to which they are to be installed.

The obvious way to distribute runtimes is to rebuild the distribution files via your installation tool of choice. If you are using InstallShield Express ‚ Visual FoxPro Limited Edition or another Windows Installer based tool, the new runtime files are available in the merge modules. Include the correct merge modules, rebuild the setup, test, and distribute. This is the safest and possibly the most polished way to redistribute the runtimes.

There is nothing limiting you from directly copying the updated runtime files to the workstation. You can copy the changed runtime files from a network server to each workstation via something as simple as a DOS batch file, create a self-extracting zip file to be run on each workstation, post them on a web page with instructions to download them, burn them on a CD with an auto play that copies them, or have a process check for new updates each time the application is started to see if an update is available. The runtime files (VFP8R.dll/VFP7R.dll/ VFP6R.dll and the language resource file) only need to be registered using REGSVR32.EXE if your application uses Active Documents or are not loaded in the Windows System folder. Taking this approach might be the easiest way if you are on-site at a client ‚ s location, in a corporate environment, or just need to move a couple of runtime files to a couple of workstations.

In the past many developers thought they needed to build a complete install package each time they needed to load new runtimes, but in fact you have many alternatives. The method of getting the runtime files to the client workstations depends on many factors. You need to evaluate the problem and determine the best mechanism for the situation.

Third party controls and libraries

The hardest part about dealing with ActiveX controls is finding Visual FoxPro examples and needing to translate Visual Basic code to Visual FoxPro code. Over the years we became good at doing this and found deploying the controls is now a close second as far as problems are concerned .

The first problem is determining what files need to be deployed. Is the file an OCX? Do associated licensing files also need to be deployed (or more importantly not deployed because they are for the development environment only)? What about COM registration and dependencies? All of these questions might make it sound difficult, but the reality of the matter is there is plenty of documentation and techniques to help developers find all the needed distribution files.

One technique we use to find the name of the ActiveX OCX file is using the Object Browser (see Figure 4 ) included in Visual FoxPro 7 and 8. The Object Browser allows a developer to browse the list of classes, constants, enumerators, events, interfaces, methods , and properties. For deployment purposes it shows us the file name and the folder where it is located.


Figure 4. Opening an ActiveX control in the Visual FoxPro Object Browser and selecting the top node displays the file name of the ActiveX control (in this case you can see the DynaZip ZIP ActiveX Control) in the lower pane.



Deploying Visual FoxPro Solutions
Deploying Visual FoxPro Solutions
ISBN: 1930919328
EAN: 2147483647
Year: 2004
Pages: 232

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net