Andrew Peacock
23rd May 2007 13:08 UTC

Including a file at runtime
  Hi,
I'd like to be able to include an optional text file at runtime. The NSIS script then reads that text file (if it exists), stores the content in a variable, and uses that variable later.

All working well.

My question is how to share this file with others.

I'm using:

IfFileExists $EXEDIRdata.txt 0 affiddone 

>

to work out where to find the text file, but that doesn't work if the installer is ZIPped. The only option is to ask the user to extract the ZIP file before they run the installer.

Is there any way to point the NSIS script to the text file within the ZIP file directly?

Regards,
Andy

Afrow UK
23rd May 2007 14:16 UTC

Why don't you have the data file in the installer, or do you need to have a static installer with a changing data file?

Stu

Andrew Peacock
23rd May 2007 14:40 UTC

The latter - static installer with changing data file,
Andy

Afrow UK
23rd May 2007 14:45 UTC

How about storing the data file on a website and downloading it with InetC? Or maybe rather than using a Zip file for distribution, use another basic wrapper installer with no UI, has CRCCheck off, extracts the two files then runs the extracted installer all in .onInit before calling Quit.

To build the wrapper installer, I would use a batch file that calls makensis.exe

Stu

Andrew Peacock
23rd May 2007 14:51 UTC

Hi Stu,
OK, alot of that was meaningless to me... but it sounds like you know what you're talking about, so I'll have a scoot around the forum and piece together the relevant code.

Thanks for the pointers!

Andy

Afrow UK
23rd May 2007 15:39 UTC

Something like this.

Name "My Installer Wrapper"
OutFile setup.exe

SilentInstall silent
CRCCheck off

Function .onInit

  SetOutPath $EXEDIR
  File data.txt
  File install.exe

  Exec "$EXEDIR\install.exe"

  Quit

FunctionEnd

Section
SectionEnd

I also put SilentInstall silent in there so that no GUI resources are added to the installer.

Stu

Andrew Peacock
23rd May 2007 15:44 UTC

Stu,
You da man!

Thanks very much. I was never really sure what the .onInit etc routines do, but I think I've got that now, as well.

Thanks again,
Andy

Andrew Peacock
23rd May 2007 16:28 UTC

Stu,
Had a look at it, and that's not exactly what I want. Mainly because I wasn't being very specific :-)

So, here's the scenario:

1. I've created an installer which can take the value of an optional text file, and use it later in the program.

2. I give that installer to resellers.

3. THEY add that text file, with their own details, that I'll never see.

4. The resellers give the ZIP (or other) file to users, who run the install, which picks up the reseller's details and installs appropriately.

So, the resellers never have access to NSIS to create a new, unique installer.

What I'd like is like the ZIP function where it asks "Do you want to extract to a folder before installing?", so that the install .exe and the data.txt file are in the same folder. The install can then work as planned.

Any chance you can shed some light on how to do this?

Regards,
Andy

theblazingangel
23rd May 2007 16:48 UTC

if thats what you want then why not use an sfx archive...

- you supply the main installer
- reseller creates the text file, then packages the two files together as an sfx archive
- end user runs the sfx archive and specifies where to extract to, the sfx archive extracts the files and calls your installer

it might be a better idea to not go down the route of asking for an extraction location though. instead have the files extracted to a temporary location silently. if you can't do this with sfx archives, it can be done by wrapping your installer and the reseller's text file in another NSIS installer, Afrow UK supplied a script for this above.

Red Wine
23rd May 2007 17:31 UTC

Provided that,
1. the text file is always wrapped in a zip with a standard name or at least a range of names
2. the zip resides into the same place with your main installer (this is preferred because the main installer won't need to perform a search to locate the zip)
You could use one of the available unzip plugins to extract the zip in a temporary place, read the required data and remove it.

Andrew Peacock
25th May 2007 12:30 UTC

Thanks for your help all. I'm looking at using server-side RAR to create a self-extracing ZIP. The reseller will enter their details into a PHP form, the server creates the ZIP, the reseller distributes the ZIP, and (hopefully) the self-extracting ZIP will correctly locate the data file.

Regards,
Andy

Afrow UK
25th May 2007 17:04 UTC

Good idea :)

Stu

chivalri
25th May 2007 18:22 UTC

I had the same issue. I have a software package that gets rebranded by some of our bigger distributors. I have created the installer so that the software gets rebranded if an ini file exists in $EXEDIR/custom. If the file is not there then the installer looks and works as usual. If it is there, the skin of the installer is changed using the distributors graphics and information and the changes are made to the installed applications.

Function .onInit
  strCpy $MyAPP_NAME "My Software"
  strCpy $DoStamp "0"
  IfFileExists "$EXEDIR\custom\custom.ini" GoodToDoStamp
  goto NoStamp
  GoodToDoStamp:
  strCpy $DoStamp "1"
  strCpy $MyAPP_NAME "Resellers Software"
  NoStamp:
FunctionEnd

Then in each section I run this code

  ${If} $DoStamp != "0"
    ${StampMacro} "This Section"
  ${EndIf}

Andrew Peacock
25th May 2007 20:44 UTC

Hi Chivalri,
Does the end user have to unzip to a folder first, or did you also use a self-extracting exe? If the latter, what's the process for getting the self-extractor created?

Regards,
Andy

chivalri
1st June 2007 22:13 UTC

Neither. In my particular case, I have created an installer that has my company's logo and text in it as well as all over the software that is installed. This is the default operation.

If a distributor wants to put their stamp on the installer and the software, they must create a sub directory from $EXEDIR named custom and create a custom.ini file in that directory that has their text changes and paths to the replacement graphics.

I ran a simple test for you using Stu's code. I added a statement to launch my setup.exe after unpacking the installer and the custom dir and then removed the installer and custom dir when done and it worked very well.

I did not make a delivery mechanism for getting the installer and the custom mods to the customer. In the instructions I provided to the distributors, I suggested they put the installer on a CD and have the custom dir there along with any other extra software they wish to add.

It works well this way.

I ran a demo for our distributors showing that if I dropped the setup.exe into 4 different folders (each with their own custom dir) I got 4 different company skins on both the installer and the applications.

Andrew Peacock
1st June 2007 22:26 UTC

Chivalri,
Ah, OK. That makes sense. I was trying to make this download only rather than CD, so that won't help in this situation.

But thanks very much for taking the time to share your experience. Much appreciated.

Regards,
Andy

chivalri
4th June 2007 15:00 UTC

My normal delivery for the file is by download and using code like Stu's I tested to verify that a single file download could contain the custom folder and the setup file and auto launch the setup file after unpacking.

For me, this works well since I am using a package based (web or cd delivery) install system. Thus the setup file is small (less than 4 Mb) and adding the extra step for a distributor to wrap the package with their "skin" does not require much extra time in the setup or download.