nsis script question: directory tree

[vonCZ]

I've a simple NSIS script for packaging my executable and a directory tree. My script looks like this:

outFile "my_installer.exe"
 
installDir .
 
section
 
setOutPath $INSTDIR
 
file ..\interface\release\myApp.exe
file /r ..\interface\data
 
sectionEnd

outFile "my_installer.exe"

installDir .

section

setOutPath $INSTDIR

file ..\interface\release\myApp.exe
file /r ..\interface\data

sectionEnd

To copy to clipboard, switch view to plain text mode 

There are no links or shortcuts in "data", just files and sub-directories w/more files & directories. I want to preserve the tree so that "myApp.exe" and "data" (with all its files & subdirectories) reside in the installation directory.

When I run the installer, however, I get:

Error opening file for writing:

.\data\a_little_test_file.txt

Abort | Retry | Ignore

What should I add so that the installer can create the necessary directories and write to them?

[jacek]

What happens when you specify different installation directory? Like InstallDir "$PROGRAMFILES\test"

[vonCZ]

Yes, that works Jacek, thanks. In my case, however: I want to install the application & its companion directory tree into the same directory in which the installer.exe resides.

After messing around with it, I found that this works:

OutFile "my_installer.exe"

InstallDir .

Section

SetOutPath $INSTDIR
File ..\interface\release\myApp.exe

SetOutPath "$EXEDIR\data"
File /r ..\interface\data\*.*

SectionEnd

This is essentially what I had before, except I'm using

$EXEDIR\data

instead of

$INSTDIR\data

$EXEDIR is "the location of the installer executable"... but since I set $INSTDIR to *also* be the location of the installer executable (i.e. "."), I'm not sure why that didn't work. It would install "myApp.exe" into the local directory, but it wouldn't install the directory tree. ...not sure why.

[jacek]

but since I set $INSTDIR to *also* be the location of the installer executable (i.e. "."), I'm not sure why that didn't work.

I think the problem is that windows don't understand "." and treat it as an incorrect name of a directory.