partymonkey
20th March 2002 16:23 UTC

RegDLL and Dependencies
  I'm trying to register a COM DLL that has static dependencies on other DLLs, but since my install directory is not the current working directory the COMM DLLs cannot be loaded (because the other DLLs cannot be found in the search path). I really don't want to install these files in the system directory (and then move them), nor do I want to install them into the directory that contains the intaller (and then move them).

Any ideas? I've already modified the installer code to support installing/uinstalling services (if you are interested in this support then let me know), but will there be any adverse effects about changing the CWD when registering/unregistering COM DLLs?

thanks,
t

partymonkey
8th April 2002 22:34 UTC

Just an update...I went ahead and added two functions GetCWD and SetCWD, and use them before registering my DLLs. I have not run into any problems with this approach.

kichik
8th April 2002 23:09 UTC

Hi t!

I have an idea:
Set the output dir to the dir of this DLL (to set the shortcut's working dir).
Create a shortcut which points to regsrv32 (I think this is the one, not sure...) to register your DLL.
Run the shortcut with ShellExec or ExecWait.
Delete the shortcut.
Set the output dir back.
DONE!

This should help you avoid changing NSIS code.

KiCHiK

tderouin
27th January 2003 20:30 UTC

Then what's the point of having the UnRegDll function if you can only use it on dll's that don't reference other dlls?

There should be a way to set the current directory.

kichik
27th January 2003 20:35 UTC

It has already been fixed in the latest version. The NSIS code has already been changed to set the current directory, there is no need for this trick anymore.

tderouin
27th January 2003 20:46 UTC

But I still get an error message saying it can't find the other dll (the one referenced but not registered) in a path that includes my $TEMP, ., and my standard $PATH, but not $INSTDIR. Any idea why?

Why would $TEMP be in that path and not $INSTDIR?

tderouin
27th January 2003 21:30 UTC

Here's some sample code that demonstrates that UnRegDll doesn't work.

  MessageBox MB_YESNO|MB_ICONQUESTION  "before change $EXEDIR"  IDYES ""

 StrCpy $R0 "$EXEDIR"

 StrCpy $EXEDIR "$INSTDIR"

 MessageBox MB_YESNO|MB_ICONQUESTION  "after change $EXEDIR"  IDYES ""

>UnRegDll "mydll"

 MessageBox MB_YESNO|MB_ICONQUESTION  "after unregistering variables $EXEDIR"  IDYES ""

 StrCpy $EXEDIR "$R0" 

StrCpy $R0"$TEMP" () ()

>Usage: StrCpy $(user_var: output) str ***91;maxlen***93; ***91;startoffset***93;

>Error in script "script.nsi" on line 361 -- aborting creation process 

>

tderouin
27th January 2003 23:47 UTC

For future reference, if anyone is interested, the way I got around this was by creating a batch file on the fly and then using nsExec::ExecToLog to execute it.

Why the shortcut approach isn't sufficient is because the links aren't opened and processed synchronously, so if you need something done in steps, it doesn't work.

uninstall stuff

  FileOpen $R0"$INSTDIR\\uninstall.bat" w

  FileWrite $R0 "regsvr32 /s /u commonrefR.dll$\r$\n"

 FileWrite $R0 "regsvr32 /s /u seg_admin.dll$\r$\n"

  FileClose $R0

  nsExec::ExecToLog "$INSTDIR\\uninstall.bat" 

Joost Verburg
28th January 2003 12:37 UTC

regsvr32 is not included in the first Windows 95 versions, so you'd better use rundll32

kichik
28th January 2003 13:57 UTC

It should work if you supply a full path for UnRegDLL ($INSTDIR\bla.dll). $TEMP is not changable because it's a system parameter unlike $INSTDIR which you can set to whatever you want.

What do you need all of those $EXEDIR changes for?

tderouin
28th January 2003 17:41 UTC

I was supplying the full path, in the first piece of code I provided I removed the actual dll name and path info.

There was thread that in this forum (http://forums.winamp.com/showthread....light=UnRegDll) indicated that UnRegDll and RegDll change the $EXEDIR to correctly construct the path to register and unregister variables, the code demonstrates that even with the correct $EXEDIR, UnRegDll still constructs an incorrect path.

kichik
28th January 2003 17:56 UTC

[un]RegDLL doesn't touch $EXEDIR. $EXEDIR is just the current directory (untill it was changed for [un]RegDLL in b0) and because of that Windows looks there for DLLs.

Are you sure that all of the DLLs it is looking for are in the same directory? In this version it sets the current directory to the directory where the DLL registered is. It takes the path from the command itself. Try the latest CVS version too, maybe something was fixed since b0 and I don't remember it, very possible ;)

kichik
28th January 2003 17:59 UTC

I meant that the current directory changes in the post.

tderouin
28th January 2003 19:37 UTC

I am 100% certain that the dlls were in the same directory, calls to "regsvr32 /s /u" from the .bat file were succesfull.

kichik
28th January 2003 19:40 UTC

Any chance I can get an example script with the DLLs? If you don't want it public you can email it to me - kichik at users dot sf dot net.

tderouin
31st January 2003 20:39 UTC

Unfortunately, that won't be possible. For now the .bat file is working sufficiently.

Thanks!