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

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"

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

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)...

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)

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



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

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

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.

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)

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

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

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