>This is just a case of weekend blues.
>
>While reviewing the code in my framework (5.0) for a possible conversion to 6.0 SP3 I happened to look again at a uitility that is vital to me. When I need to create the install/distribution files, this routine creates a new directory structure and moves all files in the project to the appropriate directory. Ex: if my app is in n:\apps\current\inventory I will direct the procedure to create a new project in, say, c:\temp\test\install\inventory. The routine will then create a new project with the same name and move all the files that make the app to a new structure in the local dir. I could have libraries in m:\fw\libs, n:\apps\libs and n:\apps\current\inventory\libs: all the .vcx files will end up in a directory called c:\temp\test\install\inventory\libs. And so on for forms, include, reports, bmps etc. The procedure will then change all references to the old paths to the new ones and compile the new project.
>
>There are several advantages, some of which are:
>if the project compiles and runs in the new location I am sure it will install almost anywhere.
>it is very easy to add files to the setup program
>I get an automatic complete backup of an installed program (for versioning, updates, etc)
>It is easy to make small exes and distribute forms and vcx with the source code removed (the utility takes care of this too)
>
>What worries me is this: i don't recall seeing threads with solutions for this "problem". Does this means that it is not a problem at all? Could it be that I have invented the wheel again?
>

For me at least, I don't have any of the problems; I've got a small program that compiles and strips source, but I really don't worry IAC, since when I sell something with the class libraries on in my executable, I'm seeling the source code anyway. SourceSafe handles versioning/backup; I'm careful to use relative pathing, and use SDT to handle table and DBC management. I only distribute the runtime files using a Setup Wizard generated install, doing everything else with InstallShield.

I have testing that I need to do, that goes a lot beyond what you mention, in order to ensure that my app runs "anywhere". There are lots of network-related and OS-related things that I need to check on and handle during the installation process; I try to make sure that common components that I need in place (DCOM, the Windows Scripting Host) and I need to know that the operating system has at least the minimal required patch levels (most of what I work on now requires Win95 with at least SR1 in place, or NT 4.0 SP3) to reliably support things that I use. In many cases, there are differences in the Win32 API that affect what API calls are available, and how they behave, too.

On the network front, I need to know if the file system supports long file names, and I have to make sure to convert stuff referenced by mapped drive to UNC references.

I don't rely on the Setup Wizard to do anything except install the VFP runtime files. Everything else is handled by InstallShield (InstallShield runs the Setup Wizard runtime install for me as one part of the InstallShield script) and it gives me a whole lot more flexibility on everything else as far as sequencing the install process.

I've been using InstallShield Pro for a while; there is a fair amount of learning curve to it, and it isn't cheap, but it's a full-blown installation language. There are less expensive options, like InstallShield Express, that offer much more flexibility than the Setup Wizard and can use a similar approach to handling the runtime install issues. And there are other people here who use other third-party products; Wise and Setup Specialist are a couple that other people here use successfully; they have specific VFP install support that will take care of the runtime issues as a part of their package.

As far as physical distribution; CDs for the initial distribution. In many cases I make downloadable updates using WinZip's Self-Extractor that automatically fires a WSH script (another reason to put WSH on the target systems!) to perform updates tasks; the WSH can easily act as a simple, lightweight installer writing VBScript or JScript to do what needs to be done. The commercial self-extractor is not a part of the basic WinZip product.

I don't even bother with floppy distribution of my basic products, and in the cases where an update is too big for a floppy and the customer doesn't want to download it, CD-R media costs $1-1.50/blank in bulk, and you can get inexpensive CD-R or CD-RW drives for under $200; I'm using an HP SureStore 8100, which is a bit more expensive, but I paid for the HP name and higher performance. Adaptec Direct CD came with the drive (along with other CD stuff) and Adaptec EZ CD Creator is a part of EZ-SCSI 5, which I have anyway, since I've got Adaptec SCSI cards or have one of Adaptec SCSI chipsets on the motherboard.