How can I programmatically read what version of software I am using?
If I use Visual Studio to create a project, and that project includes a resource (.rc) file and the version is specified in that file, how can I use code to "read" the version information?
That is, if I want the software to report what version it is when it is run, and the only place this information is stored is in the .rc file, what can I do?
You want to use GetFileVersion() and related functions.
You can use GetFileVersionInfo with the name of the current executable/dll to read the version information, which was embedded into the exe/dll when it was built from the resource file.
Assuming that you are using VERSIONINFO in your resource files, use these functions.
Related
I know I can call GetFileVersionInfo() windows API to retrieve file version information.
Is there an easier way to determine the version information, from within the program itself?
For example, suppose I am writing codes for Foo.dll, and inside Foo.dll, I want to support a version function, say GetFooVersion(), which reports the version number of Foo.dll.
If I have to use GetFileVersionInfo(), then I need to search which Foo.dll in the path that is been linked (dynamically), and apply GetFileVersionInfo(). It's tedious and error-prone.
The target visual studio version is VS2012.
There is no GetFileVersionInfoByHandle nor GetFileVersionInfoFromModule unfortunately.
You can use FindResource etc. on your own module but you then have to parse the version info yourself because GetFileVersionInfo does not always retrieve the raw resource data (it can translate to/from Unicode etc.).
Another option is to put version #defines in a .h file that your function and your resource.rc can use so you only have to update a single file when the version changes.
I want to read the file properties like File Description , Product name , Copyright of a exe file. Is there any Windows API for it?
Yes. It may not be evident to find it because the Version Information chapter is hidden below Menus and other Resources. The rationale for that is that it is stored is the executable files (including DLL) as a VERSIONINFO resource that was originally intented to help install tools to know whether the version to install was more recent than an existing version.
You will find examples for using it in the linked page to the MSDN and also in SO in different places, for example here
Those values are stored in the file's version info resource. You can use GetFileVersionInfo() and VerQueryValue() to read them.
I have the following problem with my software in Visual C++.
I've set some Build Customization related to the file in the path: $(VCTargetsPAth)\BuildCustomizations\PROGNAME 4.2.targets
On a different pc I have a different version of the same file (for ex: PROGNAME 5.0.targets); when I open my VC++ project, I have to edit the *.vcxproj file in order to set manually the new version of targets.
Is there a method to avoid this problem and make the project available with different versions of targets file?
Thank you in advance.
You might be able to do it by referencing a short cut instead. Each machine has a short cut in a known location that refers to what ever you need to refer to.
How do you change the language property of a Windows DLL or EXE? The property I am talking about can be seen if you right-click on a DLL and go "Properties" > "Details". Something from the command line would be preferred.
Background...
I am trying to get rid of a warning when building a Windows installation package using WiX. The warning is:
LGHT1076: ICE60: The file somedll.dll
is not a Font, and its version is not
a companion file reference. It should
have a language specified in the
Language column.
If you add a DefaultLanguage attribute for the file within the WiX project file, this changes to:
LGHT1101: The DefaultLanguage '0' was
used for file 'somedll.dll' which has
no language. Specifying a language
that is different from the actual file
may result in unexpected versioning
behavior during a repair or while
patching. Either specify a value for
DefaultLanguage or put the language in
the version information resource to
eliminate this warning.
I'm really not sure what the first solution they suggest means ... didn't I just "specify a value for DefaultLanguage?" So I'm trying the second solution, which I'm guessing is the language property of the file? I am building somedll.dll from source, so if it is something that has to be done when building, I might be able to do that.
A file's language is an attribute of its versioninfo resource. WiX reads it to autopopulate the language (and version) columns in the .msi File table.
Since I had access to the source, I was able to change the version resource file to include the language in this case. The specific library was Qt, the fix can be seen in QTBUG-16583.
Still not sure how one would do it without access to source.
I need to build an old VB6 application with a version number where the 4th digit is greater than 9999, for example, version 1.2.0.10003. VB6 won't let you do this; the build fails.
The current workaround is to build version 1.2.0.9999 and then manually edit the file in Visual Studio to insert the correct version. There must be a better way. Is there a command-line tool that allows you to modify the version number fields of an EXE or DLL? Preferably a way that allows you to edit specific version number fields individually.
ChangeVersion (and others) taken from:
How do I set the version information for an existing .exe, .dll?
There are a number of tools for editing the version info of a windows executable but I don't think you will need them.
Look here are using resource files in vb
http://visualbasic.about.com/od/usevb6/a/ResVB6.htm
And here for info on the version resource
http://msdn.microsoft.com/en-us/library/aa381058.aspx
And here for info on the microsoft resource compiler
http://msdn.microsoft.com/en-us/library/aa381042(VS.85).aspx
With these two you should be able to disable VB's builtin versioning and use whatever version info you want.
Nevermind, VB6 inserts its own version resource as a post build operation with no way to turn it off. Overwriting the version info in the executable is the only solution.
See http://www.darinhiggins.com/?s=%22resource+files%22
Resource Tuner Console
This console resource editor allows creating a reliable and repeatable
process for updating Product Version Information resources during the final
stage of the build process from the command prompt.
See specifically the batch manipulation of file version information page for greater details:
http://www.heaventools.com/rtconsole-update-version-info.htm
StampVer
I think editbin might be a better solution (installed with Visual Studio)