Re: Beta Release of ASCOM-Standard Platform version 6.4RC1
Robert Hoskin <r_hoskin@...>
toggle quoted messageShow quoted text
Just a little painful experience (life in IT as well as w/ASCOM). The Windows Registry is... 'complex'. Some complexity coming from Microsoft, and some coming from the way some developers use it. It's a remarkable product de-installer that actually removes everything that the *installer* put out there in the first place. Hence the occasional need for products like CCleaner, that do registry scans and try to clean up dangling detritus.
The user/installer doesn't really experience a problem from an incomplete deinstall until they start doing sequences like install-deinstall-install, such as during upgrades, or repetitive installation troubleshooting. At that point, they can start bumping into registry entries left from the previous install, and that can have them tearing their hair out, because they may have this problem that won't go away, and they don't understand why - because they trust the deinstaller to do a good job.
Most Enterprise software I've worked with tended to use the Registry for just the entries they needed, to keep the Microsoft environment happy, and then put everything else (application and site-specific parameters, paths, etc.) out in config files, ini files, xml, or other data structures. I much prefer that, as it reduces risk from registry problems and makes stored parameters, etc. easier to work with. Reduces risk, doesn't eliminate...
I ran into this with ASCOM, when my mount became confused about its park state (see my Dec 19 post). I think what happened was that something went wrong and left ASCOM's record of the mount's state in the Registry inconsistent, and ASCOM was unable to cope with that, when next it ran.
Like most software users, I ran the Programs-and-Features deinstaller and expected it to work. Then reinstalled, and still had my problem..and many of my config settings... Then deinstalled again, and took a look at the Registry. It was hardly touched, and many entries remained - they store everything they can, in there. The registry is hierarchical, so you have to drill entries to find things, and the meanings are not always clear. I'll poke Registry values if needed and based on good understanding, but I lacked understanding needed to fix my Park-related entries, so that was out.
I subsequently found that standalone deinstall utility, ran that, and it cleared out most of the ASCOM Registry entries. That was probably sufficient, but by that time, I had blood in my eye, and I gave CCleaner a turn at the Registry. It did find a few more things to remove, but I think they were probably harmless. A fresh install, and I was back in business.
Call me gunshy... :-) A platform upgrade puts you in the install-deinstall-install scenario I mentioned above. I think that thread I linked will get you started on the deinstall/install procedure needed for the RC, but I'd double-check ASCOM-Talk to see if there's more before starting.
Hope this helps...
From: "chris_moses@... [ESPMC-Eight]"
Sent: Tuesday, May 15, 2018 11:04 PM
Subject: Re: [ESPMC-Eight] Re: Beta Release of ASCOM-Standard Platform version 6.4RC1
You obviously know more about ASCOM than I do, which is why I ask - Do you mean an internal repository pattern? What is wrong with that?
It's been a while since I did any ascom programming. Looking forward to geting back into it.