>>>>What about this? How about the VS Installer as an automation server? Hmmm? Consider the possiblilities there.
>>>
>>>What would control it? IOW, whose the client? A VBS script?
>>
>>Control from VFP or VB script or whatever you like. In VFP, it'd just take a small prg to do the work for you. Provided what functionality was exposed, theoretically, you could automate the whole process.
>
>And then compile and distribute that? Are there two different files, one that houses the VFP code, and one that houses the compressed distributables? Maybe this is all trivial, but it seems to me at first glance that an installer has to be somewhat of a self-contained product, because it does its job on the client side. It can't use COM interfaces, because it would have to include the dlls, extract them, register them, and then use them for the rest of the install. Since a lot of what an installer does is this sort of functionality anyway, now you have completely duplicated functionality in the distrib file. With the idea of automation from an install comes a lot of chicken and egg questions. Dig?

If you make the WSH available, you could create a COM Object to encapsulate the functionality of the Setup API and use that to do much of the task. The Setup API takes care of resolving locations, decompressing files, checking time-date stamps and versioning, and can even be used to handle much of the requirement for delayed copy-and-register operation. OTOH, it's a lot of work, would need lots of testing and debugging, and by the time you finished getting it to work, the cost of a high-end installer would not seem unreasonable...