madden
29th December 2009 11:58 UTC

Create installer with the same version as the main application executable
Hello

I would like to always version my installer with the same version as the main executable in the packaged application.

Can I read the version info resource from an executable at compile-time and then set the Output file name to include it or set the version info instructions to include it ?

Thank you,
Timothy Madden

Wizou
29th December 2009 17:05 UTC

for this, I use a small command-line tool I made, which takes an EXE and generates a NSH script.
So I call my tool in my NSI script with !execute, and I !include the result:

!execute "mytool.exe mainprogram.exe output.nsh"
!include "output.nsh"

Wizou
29th December 2009 17:08 UTC

by the way, this small tool can be an executable made with NSIS, using GetFileVersion

madden
29th December 2009 18:13 UTC

I think that is a nice idea.

I resorted to installing exiftool to read the version info from the command line, and then use a makefile with some commands that parse exiftool output and invoke makeNSIS with /DPRODUCT_VERSION=%%i on the command line.

After that I found out I can also use !search... to have makeNSIS scan the resource file in my project and take the version info (version number, product name, company name) from there... :)

But I agree that generating and launching a small NSIS installer (with a few !system directives) works without any external tool and without any application source code files.

Come to think of it, it would also be a good idea to check that resources in the executable are no older than the resources described in the source file (to check that I have recently compiled my program before creating the installer)...

Wizou
9th April 2010 16:36 UTC

I released my tool here: http://wiz0u.free.fr/prog/PETool/
Using PETool.exe <exefile> /NSIS <header.nsh>
it will generates a header.nsh file with the useful version information taken from the EXE (or DLL)

BTW, this tool has many other useful features that one can use in the building process, like tweaking version informations or changing resources (for example, it can be use to "brand" an executable)

niteflyer
13th April 2010 09:16 UTC

I have made a headerfile some time ago, which has a macro for this purpose:

http://nsis.sourceforge.net/NfUtils_...SetVersionInfo

It uses the same technique described in Wizou's first post...

grassu
15th April 2010 01:11 UTC

petool.exe is crashing on win7 64bit
Dear Wizou,

I just downloaded your petool.exe and tried to execute it on a win7 64bit system.
Petool is crashing and creates just an empty output.nsh file.

Any idea?

Thanks,
grassu

Wizou
15th April 2010 08:48 UTC

mmmh no idea... I don't have such a configuration to test on...
I will take a look at the source to see what could be a problem.

pengyou
15th April 2010 12:59 UTC

PETool v1.5 works OK on my Windows 7 64-bit system. Attached is the output from the command:

PETool.exe ChromeSetup.exe /NSIS example.nsh

(I changed the output file's extension so I could upload it here)

Wizou
15th April 2010 13:22 UTC

thank you pengyou!
so I guess it must be the EXE/DLL that grassu was trying PETool on, that made it crash.

grassu
15th April 2010 14:39 UTC

Thanks for your reply and for your nice tool.

I think I found the bug. Petool doesn't like relative pathes.

Example:
petool.exe resides in c:\tmp\test\petool.exe
firefox.exe resides in c:\tmp\firefox.exe

When I call petool like this it works:
C:\tmp\test> petool.exe c:\tmp\firefox.exe /NSIS out.nsh

but calling it with relative path it crashes:
C:\tmp\test> petool.exe ..\firefox.exe /NSIS out.nsh

Any idea,

Christian

Wizou
15th April 2010 16:24 UTC

Thanks for this report. I will check that out
This is probably due to the way I handle wildcard expressions.

Ex: PETool.exe *.exe /SHOWSTAMP