How rreliable is the CLSID method of obtaining a file location?
in [Visual Basic]
|
Prev: problem emailing attachment with COD method
Next: Loading Excel via VB - Resize issue with over 255 characters in a
From: Randem on 9 Jul 2010 02:12 And for registered files: Enumerate HKEY_CLASSES_ROOT,\TypeLib\ -- The Top Script Generator for Jordan Russell's Inno Setup - http://www.randem.com/innoscript.html Free Utilities and Code - http://www.randem.com/freesoftutil.html "Tony Toews" <ttoews(a)telusplanet.net> wrote in message news:qkbd365ucbhjab87nem8dvqmadrikf5v4s(a)4ax.com... > On Thu, 8 Jul 2010 18:05:35 -1000, "Randem" <newsgroups(a)randem.com> > wrote: > >>Auto FE Updater? What does the FE stand for? > > Whoops. Sorry this is the utility I'm working on and about which I've > been asking lots of questions these last few months in this > newsgroup.. FE is for Front End file meaning the Access front end > database file containing the linked tables, queries, forms, reports, > macros (if any) and VBA code which is usually distributed to the users > PCs. > >>I am not really sure of what your endgame is but the problem with checking >>for MDAC versions and such is that certain applications that were not >>packaged correctly may have installed only parts of an MDAC (just a few >>dlls) on machine which could give you the wrong information about what is >>actually there. The way I have handled this was to automaticall update the >>machine to the latest MDAC, JET and DCOM and this has solve connection and >>application errors for this will bring all components to the same level. > > Understood. All I want my utility to do is to log hese version > mismatches in a few key DLLs so the developer can take a look on an > occasional basis and decide if it's worth worrying about. My utility > is designed to be a drag and drop deploy by the Access developer onto > the file server and to not require any admin rights. > > So from that perspective it's far better to use the CLSID method of > obtaining the path to the DLL rather than dependeing on the DLL being > ina specific folder. The idea being thatsome rogue install routine > installs and registers the DLLs in a bad location. Which in turn > could screw up other software. > > Tony > -- > Tony Toews, Microsoft Access MVP > Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm > Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ > For a convenient utility to keep your users FEs and other files > updated see http://www.autofeupdater.com/
From: Randem on 9 Jul 2010 02:28 One of my post went missing, here is what it said: Ok, in that case use the CSLID to find the file, also use the shareddll area of the registry. This will tell you exactly where the the files that are registerd and shared are. located. If you need exact locations I can look them up. It's been a while since I looked at that area. -- The Top Script Generator for Jordan Russell's Inno Setup - http://www.randem.com/innoscript.html Free Utilities and Code - http://www.randem.com/freesoftutil.html "Tony Toews" <ttoews(a)telusplanet.net> wrote in message news:qkbd365ucbhjab87nem8dvqmadrikf5v4s(a)4ax.com... > On Thu, 8 Jul 2010 18:05:35 -1000, "Randem" <newsgroups(a)randem.com> > wrote: > >>Auto FE Updater? What does the FE stand for? > > Whoops. Sorry this is the utility I'm working on and about which I've > been asking lots of questions these last few months in this > newsgroup.. FE is for Front End file meaning the Access front end > database file containing the linked tables, queries, forms, reports, > macros (if any) and VBA code which is usually distributed to the users > PCs. > >>I am not really sure of what your endgame is but the problem with checking >>for MDAC versions and such is that certain applications that were not >>packaged correctly may have installed only parts of an MDAC (just a few >>dlls) on machine which could give you the wrong information about what is >>actually there. The way I have handled this was to automaticall update the >>machine to the latest MDAC, JET and DCOM and this has solve connection and >>application errors for this will bring all components to the same level. > > Understood. All I want my utility to do is to log hese version > mismatches in a few key DLLs so the developer can take a look on an > occasional basis and decide if it's worth worrying about. My utility > is designed to be a drag and drop deploy by the Access developer onto > the file server and to not require any admin rights. > > So from that perspective it's far better to use the CLSID method of > obtaining the path to the DLL rather than dependeing on the DLL being > ina specific folder. The idea being thatsome rogue install routine > installs and registers the DLLs in a bad location. Which in turn > could screw up other software. > > Tony > -- > Tony Toews, Microsoft Access MVP > Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm > Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ > For a convenient utility to keep your users FEs and other files > updated see http://www.autofeupdater.com/
From: Tony Toews on 9 Jul 2010 02:32 On Thu, 8 Jul 2010 19:56:40 -1000, "Randem" <newsgroups(a)randem.com> wrote: >Ok, in that case use the CSLID to find the file, also use the shareddll area >of the registry. This will tell you exactly where the the files that are >registerd and shared are. located. > >If you need exact locations I can look them up. It's been a while since I >looked at that area. Thanks, I'll poke about all those. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/
From: Tony Toews on 9 Jul 2010 02:48 On Thu, 8 Jul 2010 19:56:40 -1000, "Randem" <newsgroups(a)randem.com> wrote: >Ok, in that case use the CSLID to find the file, also use the shareddll area >of the registry. This will tell you exactly where the the files that are >registerd and shared are. located. I could take this one step further. See if the key DLL exists in the espected location via the CSIDL, etc. Then see where the registered location is in the CLSID. And if they're different, especially if the version is dfiferent, give the developer who is running my utility a warning message to review that system. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/
From: Randem on 9 Jul 2010 03:43
In the locations that I gave you you will see all the versions that are installed. You can then make a determination about a possible confusion in registered dlls. -- The Top Script Generator for Jordan Russell's Inno Setup - http://www.randem.com/innoscript.html Free Utilities and Code - http://www.randem.com/freesoftutil.html "Tony Toews" <ttoews(a)telusplanet.net> wrote in message news:lfhd3653ka7acn0f84oirisjl25hfo9g8l(a)4ax.com... > On Thu, 8 Jul 2010 19:56:40 -1000, "Randem" <newsgroups(a)randem.com> > wrote: > >>Ok, in that case use the CSLID to find the file, also use the shareddll >>area >>of the registry. This will tell you exactly where the the files that are >>registerd and shared are. located. > > I could take this one step further. See if the key DLL exists in the > espected location via the CSIDL, etc. Then see where the registered > location is in the CLSID. And if they're different, especially if > the version is dfiferent, give the developer who is running my utility > a warning message to review that system. > > Tony > -- > Tony Toews, Microsoft Access MVP > Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm > Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ > For a convenient utility to keep your users FEs and other files > updated see http://www.autofeupdater.com/ |