>>>Funny thing was, even though the install, uninstall, reinstall sequence appeared to work, I'd get a error C0000005 when exiting the .exe file. After the dcom98.exe file install - it went away.
>>>
>>>I checked the dcom log file to see what files were installed. My attempt to include those files in the InstallShield install still failed to register the dll's properly, even though I had all the files included and sorted in the order of the log file.
>>
>>The DCOM98 files require configuration and registry entries that you probably don't know about. You can't trust just installing the files...
>>
>>If you use COM I guess that means you need to run either NT or make sure that IE 4.01 is installed on clients. Yuk...
>
>Rick,
>Tech Support at Microsoft (VFP) told me about this one. The dcom98.exe file is a setup file that installs and registers itself. I don't know about the configuration or registry as you mentioned. I only did as they suggested, installed it, refrained from rebooting right away to see what would happen when I did my InstallShield Installation and all my files registered. These included dynazip ActiveX and Catalyst SocketTools ActiveX Ras, MIME and SMTP ActiveX controls.
>
>Previously - all of the ActiveX registration failed as did vfp6r.dll (if memory serves me right.) There were others that also failed. I rebooted and everything worked. This was on a brand new Windows 95 installation using diskettes when 95 first came out. I did not install IE 3.0 or 4.0. 3.0 came on separate diskettes in the box. I also did not install SP1 or any other patches believing this to be a worst case scenario.
>
>If there are issues with dcom98 that are not addressed here, could you give me some feedback and I'll pass it along to Microsoft tomorrow?
>
What I've done in the past with installs requiring the DCOM98 stuff is to break the install into two scripts, one that ends my Install actions immediately after installation of the DCOM98.EXE, the second starting from that point. I then run the first script, which writes a RunOnce key into the registry that points to the second script before starting the DCOM98 install - if the user decides to reboot after running the DCOM install, the RunOnce key starts my second script after the reboot; if they don't, my first script pauses a bit, checks the completion code returned by the DCOM install and removes the RunOnce key, and then chains to the second script if the DCOM install suceeded.

There are drawbacks to this approach. First is that if they reboot, the first script's temporary files get left on the target system, since the first script isn't given a chance to fire it's cleanup applet. If you can get your users to NOT reboot, the complexity of the InstallShield scripting goes WAY down, and will always clean up after itself. For some reason, many of my users don't read the screen and just go ahead and reboot anyway

Second, you must distribute on CD and install from a local CD, or copy the entire second script to the local machine's drive and track where it gets put before the (potential) reboot and add lots of custom actions in the second script to see if it has to remove it's local image during its cleanup process. This precludes distribution on floppy, Admin installs to a LAN, or Install from the Web as options, without a whole lot more work than I've had time to devote to the problem.

This works with InstallShield 5.1 Pro - I'm not certain that the CE version gives you enough capability to write the necessary scripting.