Windows installer build process needs to check correct NSIS plugins are used
|Reported by:||Brian Smith||Owned by:||Brian Smith|
|Severity:||normal||Keywords:||Windows NSIS plugins|
Although the Windows installer for POPFile 1.1.2 RC1 was able to shut down an existing copy of POPFile the installer for RC2 went into a loop until the user manually shut down POPFile.
There were no changes to the relevant NSIS code between RC1 and RC2; the problem was that RC2 was built using several out-of-date NSIS plugins. Simply upgrading these plugins and rebuilding the installer (as RC2a) solved the problem.
The build process needs to include a mechanism to detect this sort of problem at build time. The installer already has some checks on the ActivePerl version so something along similar lines for the NSIS plugins should be relatively straightforward.
Perhaps a simple list of the extra plugins and their MD5 sums could be used as an "include" file which was used to check the plugins at compile time? This would also make it easier to document the identifying details of these extra plugins as most (all?) of them do not include any VersionInfo.