Installation problems - how to avoid?

[BruceG]

Creating a setup program for the last project I worked on was a nightmare. I tried three different setup packages, and none of them individually could create a reliable installation that would work on all Win platforms (95, 98, and NT - didn't try 2000). The setup packages were InstallShield Express 2.13, the PDW (everyone's favorite), and Visual Studio Installer 1.1.

The project used VB6 w/SP4 to connect to an Access 97 database (DAO 3.5), along with Crystal Reports 4.6 (the one that ships on the VB6 CD). For what it's worth, the FSO (Scripting object) was also used.

An InstallShield installation would go smoothly, but when the application ran, the error 429 (ActiveX could not create object) would come up. The Visual Studio installer could not register the Crystal Reports OCX during the install, and would also produce the 429 error when the app was run (I thought it was supposed to take care of that!). I was reluctant to let the PDW continue after it produced the message "Some system files are out of date - you must reboot to continue" - I had been burned by that a while back with the VB5 setup program (a user's machine was hosed); they may have fixed this in the VB6 PDW, but I'm not going to take that chance.

Although not an ideal solution, what finally worked was using a COMBINATION of two of these tools. I found that if I run the InstallSheild setup first, then uninstall the app, then install using the VSI or PDW setup on top of that, the app runs fine. But yecch - who wants to make the user run two install processes?

Any thoughts on what could have been done to make this smoother and not "confuse" the installers? Should I have used an Access 2000 DB instead of 97? Should I have accessed it via ADO rather than DAO? Should I have used the latest version of Crystal Reports? Or does none of that matter? Any opinions on what you can do to test and make sure you have a bullet-proof install?

I appreciate your input on this issue.

[honeybee]

We are in the same boat!

But I have only the PDW to burn my hands.

We are using VB6 with Access 2000.

The very first installation was the one which proved smooth. All others are either crashing in the installation stage itself or when the application runs.

First crash was due to the EXPSRV.DLL missing, or that was what we perceived from the technet. So we added this file to the setup, and then found out that it had a bug, it was marked as an auto-registering file, which it apparently isn't. In came the SP3 to fix the problem. (Meanwhile we tried to edit the Setup.lst and remove the auto-register tag from this dll entry. The installation was smooth, but then the MSSTDFMT was reported missing. When we included that in the setup, the setup could not extract this file from the cab files.) After SP3, the project stopped working. We are using two machines, and on one we installed SP3. Now the forms created in one machine cannot be accessed/compiled in the other and vice versa. So we put SP3 in both machines, but now some of the controls in one machine, the MSCOMCTL.OCX shows a tag as (SP4).

We have yet to try the other setup packages, but I think we also have to create our own distribution program.

[BruceG]

Yikes, honeybee! That is a horror story on par with mine.

To reiterate my query, are there any veterans out there who have licked this install problem and know how to create a bullet-proof setup?

Since my last post, I've taken the path of examining the file lists generated by both setup packages, seeing where they differ, and trying to modify one or other so that I can have one good, clean package. I've also concluded that it is essential to have a least one test machine that you can "wipe" and load a fresh copy of an OS on and test your install on top of it.

Oh well, the saga continues...

[Eddy]

Hi BruceG,

Well,to tell you the truth, I'm not so sure whether we are in the same boat or not. I used to face that Error 429 before. However I'm using VB6 with Paradox. And I tell you it's one hell of a time trying to solve it.

Well, I've gone thru the PDW and face that error and as well as when I tried on Installshield. Then on one fine time while doing some trial & error basis, I've managed to solve the problem using Installshield.

BUT, the problem is that I'm not so sure which one is the real culprit.Because at that time I've tried 2 options. First, I replaced some files that is connected to the type of database (which is some files which is required by Paradox) and second I run the program DCOM95.EXE (because I faced with this problem while installing in Win95). FYI, my project was developed in Win98.

So, my suggestion is that you should try to either run DCOM95.EXE before you execute your setup program (if you're installing it in Win95) OR ensure that all the files required by your Access database are in the latest version.
Hope this could help you.

[PaulLewis]

Sorry I can't offer any help on the setup issue. My projects I guess are too simple to need anything other than PDW because this has always worked for me. The biggest project used a third party control for capturing live video, ADO for database access, Intel's JPG dll as well as a couple of other controls form vb-accelerator.com. Despite having the necessary reboot on some machines, the install always worked smoothly for me... I never used any VB prior to VB6 (ok a little VB4 years ago for messing around in), and I've maintained two dev machines (home and office) with home being original VB6 and office being SP3. Both were recently updated to SP4, but even with mismatched versions I had no problems.

No for the other thing, I have found VMWARE to be great for testing installs. I could not run my app under the virtual machines due to the lack of support of the video capture but as far as installing and so on went, these worked great!

In case you don't know about vmware, goto http://www.vmware.com/ and take a look. The product allows you to run virtual machines of win95, win98, winNT, win2000 all on one machine and even simultaneously if you want! You need WinNT ow win2000 as your OS. The ability to "trash" a virtual machine, and refresh it to a standard install within minutes is very very helpful.

YOu can use your development machine for testing installs because the virtual machines have nothing to do with your local file system. I cannot recommend it enough.

Hope it helps :)

Regards

[honeybee]

I just detailed my installation woes on this thread:

http://forums.vb-world.net/newreply.php?action=newreply&threadid=36426

and don't wish to repeat here. Please take a look at this thread.

Eddy, you are right about the DCOM95 thing, but our target machine is Win 98, so that's out of question. And then I feel the DCOM95 is mainly associated with ADO, right?

As for PaulLewis, you don't seem to be a genuine VB developer! (LoL take it lightly.) Because you don't have any installation problems!

Thanks for the vmware knowledge!!

[rammy]

Eddy,

How did u connect to paradox? i need to, and am wondering whcih is the best way....

thanx

[honeybee]

BruceG and all others, I am happy to announce that all my installation troubles with PDW have gone away!

BruceG, perhaps just going along with the PDW would do the trick for you! We installed the SP4 and all the woes seem to have gotten over. The installation is literally a breeze. Only a few times the Sytem Files Out Of Date message pops up, but so far none of the target computers have been hosed (and that includes my boss' laptop and our NT server.)

I think PDW deserves another try.

.

[rikshawdriver]

honeybee is right. PDW will do the trick. Make sure you did not ignore the dependency and other errors while packaging the software. Just ignore the dependency out of date error for Crystal Report 4.6. Crystal Report 4.6 DLL does not need the dependency file suppplied with it (it is always out of date, even after a fresh CR 4.6 installation!)