At 09:24 AM 2/15/2005, Bill Stoddard wrote: >William A. Rowe, Jr. wrote: >>At 06:00 PM 2/12/2005, Bill Stoddard wrote: >> >>>If the last thing your installer does is install the service, the service >>>install will fail if there is a problem with httpd.conf. The most likely >>>problem is that some other service is using port 80 (or port 443, or >>>whatever port you want httpd to listen on). >> >>That and other issues. I have a couple theories on this... >>* Solve the port 80 (443...) problem simply by testing those >> ports in real_features.dll, a stub which our .msi invokes >> to test other real-world issues, today. Add the choice of >> ports (default: 80) and run the user in a circle till they >> choose a valid port. >>* If this is possible; Pipe the service install output to a log file. >>Present the user the results of that log file >> upon exit. Hopefully, this provides some feedback of why >> it did not install. [This is not as trivial in .msi as >> it might sound.] > >Sounds like complex solutions to a simple problem... Why not do this: >move the service install to pre_config (or rewrite_args). Then allow the >service install step to proceed through post_config as it does today. If >post_config fails, the service will still be installed but you will get a >clear error message saying your service will not start until you resolve the >issues with httpd.conf. I'll work up a patch.
Now -that- is a solution I can buy :) Clever approach and it addresses both concerns. I'd even agree that -k config should unconditionally perform the same service reconfig, and drop out the same way as -k install. Service install must still fail if the service is already installed, so not every error case can result in installing the service. But for config errors, I agree. Bill
