How to tell NSIS to use a different pluginsdir (?) + suggestions
My installer needs some plugins, which can be found in NSIS' standard-pluginsdir. The problem is that these have been updated several times since the initial release of NSIS 2 (final) and I want to include the sources and plugins, which actually have been used for the released build of my installer.
The user should be able to repack the installer with any NSIS 2 (final) build, and as I dont want him to overwrite the DLLs in his standard-pluginsdir with the versions I have included in my installer, I've put them together with my scriptsources in the projectfolder and made them public to NSIS with the command
!addplugindir '.'
in the installerscript. NSIS accepts this folder, but still refers primarily to his own pluginsdir, if the plugin-calls in my script can be resolved from this location. My 'workaround' to this, was to rename the DLLs in the projectfolder to installoptions.new.dll or something like that and call
InstallOptions.new::dialog "ini_file_location.ini"
Is there any other way to do what I want without having to rename the DLLs ?
If not, I'd like to suggest that any addplugindir-command puts the standard-plugindir to the end of the nsis-searchorder or to allow pathspecs in a plugin-call like
.\InstallOptions::dialog "ini_file_location.ini"
which is currently not allowed, according to my tests.
I'd also like to suggest that plugins should be compiled with version-information, so that it could be evaluated by GetDLLVersion. It's also more convenient for the programmer to decide which version is more recent, as he could inspect the fileprops of a DLL in his explorer.
Another nice feature would be if VIProductVersion could use the result of GetDLLVersionLocal 'AppName', so that the installer could inherit the build number of the application to be distributed, without the need to modify the script in this respect.
And, before you beat me, one last thing: the compiler does not accept SW_HIDE as showmode for ExecShell. I know, this is documented, but I don't see a reason for crippling, as SW_HIDE is already defined in WinMessages.nsh and WinAPIs ShellExecute accepts this value - it would allow hidden DOS-Boxes without the need for a plugin like nsExec.dll - afaik there already has been a thread about this...