Archive: Plugin with dependancies


Plugin with dependancies
Hi,

i would like to create a nsis plugin to manage homemade stuff before installing my software.
So i have created a project for a nsis plugin and build it.
This plugin dll has some dependencies for Qt or homemade dll (for exemple).

could it work ?


You would have to put all DLL's that the plug-in DLL depends on into the same folder as the installer EXE (aka $EXEDIR) - not into the folder from where the plug-in DLL is loaded (aka $PLUGINSDIR). For details look at the Dynamic-Link Library Search Order. Anyway, I would recommend to link everything statically into plug-in DLL to avoid dependencies. Qt can be built as static lib. Check your plug-in DLL with Dependency Walker to make sure it doesn't have any dependencies that could prevent it from loading correctly...

(BTW: The dependency on the Visual C++ Runtime libraries is another problem. Thus I would recommend to build plug-in DLL's with the static Runtime. Either that or link them against the VC 6.0 Runtime library, aka MSVCRT.DLL, which ships with Windows)


Read this article: http://nsis.sourceforge.net/Building...%29_dependency

or this forum thread where my plug-in suffered with similar issues: http://forums.winamp.com/showthread.php?t=331275


Hi,

Thanks a lot for the returns.
I will look at those links and post here how i handle things.

Guillaume


Hi,

Just for the record, here is how I handled it :
I use the SetOutPath before using my plugin functions.

ReserveFile "${NSISDIR}\Plugins\MyPlugin.dll"
...

SetOutPath $TEMP
File "MyPluginDependenciesDlls.dll"
File ...

MyPlugin::myPluginFunction
; get result
pop $R2

Guillaume


I think SetOutPath will also change the "current directory", which is why the DLL will be loaded from there. That's because the "current directory" is one of the directories that will be searched when loading a DLL (remember the Dynamic-Link Library Search Order). However the directory where the installer executable is located will always be searched first. This could result in the wrong DLL being loaded! Furthermore loading DLL's from the "current directory" is discouraged, because it can result in security problems. That's why most applications will disable this behavior by calling SetDllDirectory("") nowadays. I think you would be best off by either avoiding DLL dependencies for plug-in DLL's or, if that isn't possible, let your plug-in DLL load the required DLL via LoadLibrary() and a full path. Your plug-in DLL could determine its own location (i.e. the installer's plug-ins directory) via GetModuleFileName() and then construct the path.