Vista - How to get the file version value

Hello

How do I get the value of the file version or product version property of a
file in a VB script?

thanks

"Gavaskar" <nospam@xxxxxx> wrote in message
news:e7cM%23aP9JHA.1880@xxxxxxA method using the FileSystemObject is demonstrated in this link:

http://www.microsoft.com/technet/scr.../stfivb14.mspx

Another method using WMI is demonstrated here:

http://www.microsoft.com/technet/scr.../stfivb13.mspx

You only need the Version property of the objFile object. Note where the
file name is specified in the query, with backslashes in the path doubled.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Note that some files do not contain version information, or perhaps it is in
a format that Windows doesn't understand. If you can navigate to the folder
containing your files of interest, and add a column to display Product
Version, and the version info you want is then displayed, the
Shell.Application object can be used to get the file version info. I have
not been able to get info through the Shell.Application object for hidden
files. After learning a few things, script the process is pretty easy.

Just a few weeks ago someone asked a similar question. Here is a link to
the entire thread:
http://groups.google.com/g/78d7fef5/...7b1052f9b79238

You should find a script I authored that displays a list of column names for
all available columns for each file in a folder, but only those columns for
which there is a value for that file. As written, the script displays info
for files in the recycle bin.

To verify the script will work for you, create a test folder and copy one
file into it, one that you know has the version info you are looking for.
Change line 7 to reference your folder of interest, something like:
Set oShFlder = oShellApp.NameSpace("C:\scratch")
Also, comment out line 10, so it looks something like:
'Set oShFlder = oShellApp.Namespace(RECYCLE_BIN)

Then run the script. When I copy a file from my Adobe Acrobat program file
structure, named edb500x.dll, to my c:\scratch folder, and run the script, I
get a message box with the following info:
Name: edb500x.dll 0
Size: 584 KB 1
Type: Application Extension 2
Date Modified: 6/28/2002 10:11 AM 3
Date Created: 6/28/2002 10:11 AM 4
Date Accessed: 6/24/2009 1:34 PM 5
Attributes: A 6
Status: Online 7
Owner: Administrators 8
Company: Simple Software Solutions, Inc. 35
Description: e_Db 5.0 Expert Edition 36
File Version: 5.0.0.1 37
Product Name: e_Db 5.0 Expert Edition 38
Product Version: 5, 0, 0, 1 39

The number at the end of each line is the column number used to get the
info.

The script produces a similar message box for each non-hidden file in the
folder.

-Paul Randall



"Gavaskar" <nospam@xxxxxx> wrote in message
news:e7cM%23aP9JHA.1880@xxxxxx

Adding to the other posts:

The FileSystemObject GetFileVersion method
is the easiest, if you just want the file version.

The WMI method provides more, but not all
version info.

The Shell.Application method varies greatly
depending on OS. It's also an undependable tool
that does not actually see all files.

A 4th method is here:
www.jsware.net/jsware/scripts.php5#fvinfo

It's a VBScript class that you can paste into
any script. It works by "cutting out the middleman".
While each of the above methods calls an
available object to get what that object can provide,
this class reads directly from the file's version info.
section, in the file's resource table. The other objects
get their info. from the same place, with a
sidetrack through the Windows API. By reading from
the resource table directly the class can return
anything that's been recorded there -- including
Comment, FileDescription, etc. -- and not just the
parts made avaiable through a given scripting object.

a

Hi mayayana
I'm working (occasionally) on a script that recurses through all folders on
a drive that are accessible to the FSO, and which compares the folder's
files and subfolders collections to the items available in the equivalent
shell folder items collection, noting the things that are in one of the two
objects (fso vs shell.app) and not in the other. So far I have found that
shell.app folders do not reveal hidden items, even though the items
collection filter property has a masking bit associated with 'hidden',
according to the MS Online docs. Maybe I haven't figured out how to use
this 'hidden' bit.

Do you have a script that demonstrates the 'undependable tool' shortcomings
that you talk about, on WXP? I don't have an older system to play on. Is
it only hidden files or are there others that don't show up for you?

Oops. I just tried groups.googling for 'shell folder items filter
group:*.scripting.vbscript', and found a sample script that includes the
hidden files. Here is the script with a few modifications:

Const iFolders = 32, iFiles = 64, iHidden = 128
Set oShell = CreateObject("Shell.Application")
sPath = "D:\VBScript\Test Filter Hidden"
sFilter = "*.txt"
Set oFolder = oShell.NameSpace(sPath)
Set oFolderItems = oFolder.Items()
oFolderItems.Filter iFolders + iFiles, sFilter
WScript.Echo "Non hidden filtered .TXT files count = " & oFolderItems.Count
oFolderItems.Filter iFolders + iFiles + iHidden, sFilter
WScript.Echo "Hidden filtered .TXT files count = " & oFolderItems.Count
if oFolderItems.count = 0 then WScript.Quit
For Each oItem In oFolderItems
WScript.Echo oItem.Path
Next

I created a single hidden .txt file in the folder with my script, and it
produced the following results:
Non hidden filtered .TXT files count = 0
Hidden filtered .TXT files count = 1
D:\VBScript\Test Filter Hidden\New Text Document.txt

It seems counterintuitive for the first of the following statements get a
collection of all non-hidden files and the second statement to expand that
collection to include hidden files while also contracting the collection to
only those files with an extension of .txt.
Set oFolderItems = oFolder.Items()
oFolderItems.Filter iFolders + iFiles + iHidden, sFilter

My Shell32.dll is file/product version 6.00.2900.5622, and OS is WXP Home
SP3.

-Paul Randall

"mayayana" <mayaXXyana@xxxxxx> wrote in message
news:%23MXbPnQ9JHA.3544@xxxxxx

Interesting. I was about to say that I've
never heard of Filter. It turns out this isn't
the first time I've never heard of Filter.

http://groups.google.com/group/micro...ript/browse_th
read/thread/25b9de6a9d2721ec/033406db000254b6

But it's not in my older copy of MSDN. It's not
on my system (Win98SE). And I don't see it on
the MSDN page:

http://msdn.microsoft.com/en-us/libr...00(VS.85).aspx

Unfortunately, while MS used to be very thorough
about listing libraries and versions that support
a specific method, object, interface, etc., they seem
to have stopped doing that. But I'm assuming the link
above is the latest version.

So apparently Filter works starting with some shell
version after 98SE, but is undocumented? It's an
interesting method. If dependable then it seems to
be a powerful, easy way to list specific file categories.
But for me, at least, if it's not on all Windows versions
then I try to avoid it. I like to stick to code that I know
is dependable on Win9x up.

I've been wary of using Shell because it's really
dealing with display rather than the file system.
So it seems like it's asking for trouble to enumerate
files with it. I've never systematically mapped out
the abberations. I originally noticed it because I
had written a custom folder.htt on Win98 and added
a function to list files. At some point I noticed that
hidden files and "system-type" files were missing from
the list, even though my settings were to show all
files. I found that at least .DLL and .DRV files were
being left out. On XP I haven't seen that, but I did
find that hidden files were left out and that the Explorer
view settings had no effect on that. Another quirk is
that folders show 0 size. (I don't know if that's true
on all Windows versions.)

So I figure that it's better to just stick with something
like FSO when dealing with the file system, but of course
that's not feasible if one is doing something that only
shell can do, like checking extended properties of files
on XP.
ontwoshortcomingsoFolderItems.Counttoof

I often want to scream about not being successful at finding something at
MSDN that I know should be there. My current beef is that MSDN won't let me
see/download the Vista Recover CD ISO file that Microsoft worked so hard to
create, for those whose computer manufacturer failed to provide this
function on a bootable CD/DVD. I did find the download here:
http://neosmart.net/blog/2008/window...disc-download/, but it
requires Torrent. That turned out to be relatively easy and I have the ISO,
but not directly from Microsoft, so I have less confidence in its validity.

I went to your msdn link, and found that it pertains to the FolderItems
object. On the left side of the that page is a header item "Shell Objects
for Scripting ..." which is truncated to "Shell Objects for" when IE6's text
size is set to what I am comfortable with. I guess Microsoft hasn't learned
enough about HTML and style to build web pages that make adjustments for IE
user's preferences. Or maybe this is just a way to prod people to the
latest IE.

The Folder item in the list probably describes the members of the original
shell folder. The Folder2 item in the list describes the all the members of
the shell folder, implemented by some newer DLL. Not listed is a Folder3
item that my WXP SP3 has, which further extends the members of shell
folders.

Filter is a method of a folder items collection, so you should find it
within one or more of the three FolderItems links on the left side of the
page you referenced. FolderItems3 seem to be the first one to implement the
Filter method and is the newest one reported by TLViewer on my system.

On the folder size issue, since a folder window does not display its
subfolder's sizes, the shell.application folder cannot give that info.

Thanks for sharing your reasons for distrusting shell.application.

-Paul Randall

"mayayana" <mayaXXyana@xxxxxx> wrote in message
news:uzR05%23S9JHA.4944@xxxxxx

textlearnedIEI think they also systematically degrade the whole
system in order to encourage MSDN subscriptions. With
broken links, malfunctioning pages, and numerous redundant
pages used for each topic, no one can realistically use
MSDN online. So I guess theoretically that means MS
sells more subscriptions. I don't think I've ever actually
gone there directly myself. I find topic info. through Google.
Sometimes MS happens to have the best answer.

Their latest change has resulted in no vert. scrollbar
for K-Meleon. Though it does work in Firefox OK. So I
have to switch to Firefox when visiting MSDN. (Sometimes
in the past it's been so bad that I have to load
their pages in Firefox with "no style" in order to
read them at all.)
I downloaded a page and CSS the other day, out of curiosity,
to see what the problem was with the scrollbar. It's very
strange stuff. Their CSS file, for instance, specified
HTML {overflow: none; ... and
BODY {overflow: none; ...
Weird. But it's just too much to sort out. They're using 3
CSS files, a dozen or more script files, and a bloated mess
of WYSIWYG-generated HTML.
ofI found the FolderItems3 page, but like all of the
other new pages it says nothing about supported
platforms.