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 00:05 Auto FE Updater? What does the FE stand for? 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. Ref: http://www.randem.com/softwaresupport.html -- 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:gb6d36d47iqtqepf72kkja49i2o3hugiq1(a)4ax.com... > On Thu, 08 Jul 2010 18:11:44 -0500, ralph <nt_consulting64(a)yahoo.net> > wrote: > >>[Note: As I know exactly squat about your problem domain, what follows >>can be safely ignored. <g>] > > This is for my Auto FE Updater utility which is in use by many > different organizations around the world. > >>Probably better and certainly easier is simply require all users to be >>using the latest 'n greatest for ADO and DAO. > > Basically I want to present the developer who is using my tool with > all the versions present that the users are using. So they can decide > if there is a problem somewhere. > >>ACE/Jet will depend on the version of Office/MSAccess installed. >>So far ACE seems to be maintaining decent backward compatibility. >>There may be a need to support Jet components previous to 2000, but >>again that would be only for legacy Apps. > > Most of the start method options in my utility start up MS Access by > interrogating the registry in one fashion or another and locating the > exact path to msaccess.exe. I then look at the first component of > the msaccess.exe version and decide which ACE/Jet version to look up. > As I do have A97 installed, and a few folks out there are still using > it I choose to go that far back in my logic and do log DAO 3.5/Jet > 3.5. > >>I would think a simple track of the O/S and the Office/MSAccess >>version installed on the Users box would be sufficient to diagnosis >>most problems that might appear. > > I'm a paranoid pessimist. > >>Some users may need to support special legacy situations - you could >>make a comment for the exceptions. > > If someone is still using A2.0 out there and asks me and if I come > across my A2.0 disks which are archived to a CD/DVD somewhere then > I"ll install it. And spend the 10 or 20 minutes to go through the > coce to support it. But I expect the chances of that to be quite > small. > > 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: ralph on 9 Jul 2010 00:35 On Thu, 08 Jul 2010 14:53:13 -0500, Paul Clement <UseAdddressAtEndofMessage(a)swspectrum.com> wrote: >On Thu, 08 Jul 2010 14:22:45 -0500, ralph <nt_consulting64(a)yahoo.net> wrote: > >� >Using the Registry would be a crapshoot at best, especially with MDAC and WDAC. As a matter of fact >� >I don't believe that msado15.dll is associated with any CLSIDs. >� > >� >� What a bizzare statement. But I guess it will depend on what you mean >� by "associated"???? > >I chose not to elaborate. I did not find any CLSIDs that referenced msado15.dll directly. I gave you one. [HKEY_CLASSES_ROOT\CLSID\{00000535-0000-0010-8000-00AA006D2EA4}\InprocServer32] "C:\Program Files\Common Files\System\ado\msado15.dll" That CLSID references the ADODB.Recordset Interface. Using that CLSID directly references the Registered component that supports that interface - providing the filename and location. Location is only one of many items that are required and are directly referenced by CLSID for a COM component to be registered. >... My >understanding is that the interfaces are registered through the ADO version specific type libraries. > Interfaces are registered by using a registration utility on the component that supports those Interfaces. That's how the "location" portion of a registered component is filled in. Type library information is only part of the data that a component can or needs to supply for it to be properly registered. You can register Type Libraries separately, but they provide only declarative information. The msado15.dll component contains multiple Library, Class, and Interface information. It is also not the easiest of the COM programmer's art to understand, since the finished product, an 'ADO Object', is often an aggregate using Interface inheritance. Thus not as straight-forward as the simple VB ActiveX Dll often used in COM tutorials or examples. The beauty of COM is one sees a nice flat logical 'Object' no matter what the actual physical make-up might be. -ralph
From: Tony Toews on 9 Jul 2010 01:13 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 01:56 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: Randem on 9 Jul 2010 02:10
Here is the registry location: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs" -- 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/ |