Will, Thanks for initiating this discussion. It's been due for a while. My comments below...
> DQSD is difficult to install. There are a lot of reports of problems, and > as far as I can see, they're nearly always caused by a failure to get the > right version of the ActiveX DLL installed and registered. There's a > whole performance of logout/login which is difficult to get right, doesn't > always work properly (depends on platform, I think), and often gives the > impression that an upgrade can work without a reboot when it can't. > > This beta has been particularly bad, because there have been a lot of > additions to the ActiveX control, so no version of the beta will load with > the previous version's DLL. Agreed. Largely my fault I'm afraid. > 1. Install script doesn't have uninstall code for the 'current' version > (i.e. it deletes DLLs up to the previous version, but not the current one) > > 2. DLL version number is not being bumped for the beta revision > points. This defeats a load of code in the install script which does > version comparison. > > 3. AFAIK, we're not changing Progids/GUIDs on the ActiveX interfaces when > we change the interface. We probably should be. Have you had success with this? My experience has been a maintenance nightmare. Not to say it isn't the correct thing to do. > 4. How does the installer actually handle installations to locked > files? Does it do something like a SetupInstallFileEx which means that a > reboot is really required? I see that the script is supposed to warn that > the file's not been unloaded, but I've never actually seen that warning > appear even though I've had installation failures. Don't know. It should do something in the case of locked files. I assumed NSIS did something with the runonce registry entry in the case of locked files, but I've never looked into it. > 5. We could have some startup code in (or called by) search.htm which did a > rather more controlled check of DLL version and displayed something more > helpful than having random script errors after the bar has apparently > loaded OK. Agreed. > 6. We could have some kind of external (?) diagnostic utility which would > report what the current setup actually was and put that onto the clipboard > so that people could make better bug reports. Great idea. > What do people think? Maybe I'm the only one who thinks this needs > improvement.... Not at all. > Will _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Dqsd-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dqsd-users http://sourceforge.net/mailarchive/forum.php?forum_id=8601
