Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
DCom98 - Fatal Error
Message
From
28/11/1998 19:59:01
 
 
To
28/11/1998 18:53:51
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00162142
Message ID:
00162174
Views:
30
>>>I have a readme file from Microsoft that says you can send users to a website to get DCom98 or distribute it with your application.
>>>
>>>I would like to distribute it with my application and I am using the VFP 6 setup wizard. If DCom98 is not installed on the machine I get the "Fatal Error" when the setup program is executed but the install will continue.
>>>
>>>Does anyone have any suggestions on how I can detect if DCom98 needs to be installed and install that first?
>>
>>DCOM has been installed if the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\OLE has a registry value EnableDCOM present with a value of "Y". It may have been installed explicitly from the DCOM executable, or as a part of the IE 4.0 installation.
>>
>>>
>>>Microsoft says that the machine needs to be rebooted after the install . . . Is that capable in the VFP 6 setup wizard?
>>
>>The VFP Setup Wizard install is not capable of managing a split install; I've usually used an InstallShield or Windows Scripting Host script to manage the DCOM install, or left it as a responsibility of the installer prior to performing the VFP install.
>
>Hello Ed!
>
>Where did you find this info about DCOM98?

LOTS of experimenting. I've known about the reboot issue with DCOM for a while (it's not the only canned component from Microsoft that may cause a reboot) and have come up with a couple of approaches to incorporating the DCOM setup into my installations. All are based on a similar approach; split the installation into two separate parts, once before and up to the DCOM install, and the remainder afterwards. If DCOM needs to be installed, copy down the folder structure necessary to complete installation after DCOM gets installed (this often involves writing an INF file or some other readable file that can hold values like target directories and program groups to be used in the second part of the install), and place a RunOnce key under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion (depending on sequencing and operating system, I write either a RunOnce, a RunOnceEx or a RunServiceOnce key value) to start the second part of the installation. I then fire the DCOM installation .EXE as appropriate. If control is retuned to my script after DCOM completes, the user elected not to reboot, so I remove the RunOnce (or whatever) key value and fire the second script myself, and set it to force a reboot after the installation completes. If control is not returned to my script, DCOM triggered a reboot, and the RunOnce starts the second script for me. It's messy, and requires really thinking through the sequencing and packaging of installs (not a bad thing to do in any case.)

Since this involves things that must fire before a post-setup executable, particularly one written in VFP, can be executed, the Setup Wizard really isn't capable of doing the job, even hacking the .INF and .STF files. So I write wrappers (InstallShield Pro, and I've experimented with WSH) to handle sequencing component installs, including DCOM, the appropriate VFP Runtime install from the Setup Wizard and other canned install packages, and to provide the scripting needed for things that require custom actions. A fair amount of the custom activity involves running applets written in VFP once the necessary VFP (and DCOM) components are in place to set up files, dynamically build shortcuts and the like (I rely more and more on the automation objects from Wscript like Wscript.Shell and Wscript.Network, and the Shell.Application object, and have experimented with some ADSI object manipulation.)

Incorporating WSH into the install process gains lots of flexibility; you can build dynamic scripts using VScript and JScript and use these scripts in your install process. I use a fair amount of dynamically constructed VBScript with WSH for my more involved Admin installs, where I put a network install out for workstations to use to install my application; VBScript lets me build things for the workstation based both on decisions made during the Admin install and on values found on the local machine. You can do some amazing things with scripting.


>
>TIA TIA
>
>BB
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform