Finding program/"component" version info

  • Thread starter Thread starter jeffc
  • Start date Start date
J

jeffc

Not sure exactly what my question is or what forum to ask on.

I know how to get version info from a particular file.
e.g.
FileVersionInfo.GetVersionInfo(filePath)

What I'd like to do is get version info for Microsoft "components" such as
MDAC, DAO, MFC Runtime, etc. An "overall" level rather than specific file
version. For example .NET - 1.0 or 2.0, MDAC 2.5 or 2.7, etc. Any way? Or
better forum?
 
Unless you know which files definitively define those components, you
aren't going to be able to get it programatically. There is no versioning
API that works on a "package" level like that.

The closest thing I can think of to do this would be to have a list of
files which are distributed with those packages, and check the file versions
for each of them. If they match that list of files (and their versions)
then you have that version of that package.
 
Nicholas Paldino said:
Unless you know which files definitively define those components, you
aren't going to be able to get it programatically. There is no versioning
API that works on a "package" level like that.

The closest thing I can think of to do this would be to have a list of
files which are distributed with those packages, and check the file
versions for each of them. If they match that list of files (and their
versions) then you have that version of that package.
Click to expand...

That's what I was afraid of, thanks.
 
Hi,

I do not think this is the correct group, We could tell you how to get the
version info of a .net assembly. very easily :)

You might get a better answer in one of the C++ NGs
 
Huh? This is a C# question.

Ignacio Machin ( .NET/ C# MVP ) said:
I do not think this is the correct group, We could tell you how to get the
version info of a .net assembly. very easily :)

You might get a better answer in one of the C++ NGs
Click to expand...
 
Nicholas Paldino said:
in message news:[email protected]...

That's what I was afraid of, thanks.
Click to expand...

That's not entirely accurate in my experience (though you may have to resort
to it depending on the component). .There's no offical API that applies to
all "components" but each component will often (usually) have a way of
checking. It may rely on an official technique such as MSI or even (often)
an official registry key but in some cases the technique may be crude or
even unreliable (possibly not compatible with future releases). For
mainstream components however there are usually ways that are reliable in
practice (for MDAC for instance, see here:
http://support.microsoft.com/kb/301202 - MSFT acknowledges it may not be the
most reliable way but it likely is). The story runs deeper however since
other issues can come into play. For instance, you may simply be able to
check the version of Windows at runtime. Some components are pre-installed
with certain versions of the OS for instance and I even have a MSFT link
somewhere for this (I'll try to dig it up for you). Even if they are
pre-installed however (meaning that you can just check the version of
Windows you're interested in and it should be installed in theory), they may
not be Windows protected files so some other poorly written install app
could have overwritten them with earlier versions (or perhaps it can be
officialy disabled using Windows itself). Also consider that you may be able
to simply ship and install a component's redistribtable which should be
robust in the presence of earlier versions (you should check this). You
really need to research the subject in general but ultimately you'll have to
check each individual component to see what MSFT officially says about it
(which isn't always easy to track down).
 
Larry Smith said:
For instance, you may simply be able to check the version of Windows at
runtime. Some components are pre-installed with certain versions of the OS
for instance and I even have a MSFT link somewhere for this (I'll try to
dig it up for you).
Click to expand...

That doesn't seem like the best option for us because of the stuff our app
installs. We include merge modules for all kinds of Microsoft components,
so I'd like a way to determine what's there after we install (after the
customer might have patched our app or botched installs of multiple versions
of our app.)

Thanks for your reply, that was helpful.
 
That doesn't seem like the best option for us because of the stuff our app
installs. We include merge modules for all kinds of Microsoft components,
so I'd like a way to determine what's there after we install (after the
customer might have patched our app or botched installs of multiple
versions of our app.)

Thanks for your reply, that was helpful.
Click to expand...

You know your app best of course. This link might be useful anyway (note
that it's not confined to just DLLs in spite of the misleading name).

http://support.microsoft.com/dllhelp/
 
Back
Top