Suppose I have two nsi files demo.nsi (compiles to demo.exe) and setup.nsi. (compiles to setup.exe). I want to use demo.nsi inside setup.nsi in such a way that when setup.exe is executed, it compiles the demo.nsi, and then executes the demo.exe.
Just want to know if that is possible to do in nsis ?
Thanks.
Sure, it could be possible like from e.g. any batch file:
you need to call ExecWait to call makensis.exe for the compilation part
and you can call the final executable with either ExecWait or Exec depending on you need to wait for the result or not.
Beware that if you want to do that in any host, and not only the one where you prepare your setup, you will have to embed the NSIS distribution in your setup to be able to call makensis.exe and all the included files that could be necessary (included files, plugins, and other resources).
Related
Is it possible to use as an output directory not only one location?
Something like this:
[Setup]
OutputDir=C:\MyProject; C:\Installers
No, you cannot.
If you are compiling the installer as a part of a larger build process, you can clone the output files as part of that.
See also:
Run a [Code] or PowerShell script in Inno Setup compiler
One possible hack would be to execute some script in the background using preprocessor (as shown in the answer to the question above). And have the script watch for changes to the output file and copy it over to the other destination.
I have an installer exe which takes a channel_id param as a command line parameter and uses it.
The channel_id may be different for different downloads and installs.
I want to host my installer exe on web in such a way that when it's downloaded and executed (by double clicking) the channel_id is passed to it in someway ,which should be equivalent to running the installer exe in cmd with channel_id as below.
cmd> myinstaller.exe channel_id.
How is it possible to do so ?
You can append data to the end of the .exe file.
You can include your param in the name of the file. For example, instead of setup.exe, call it setup_XXXX.exe. Then from NSIS you can read and parse $EXEPATH and extract your param from the filename.
Probably not the most reliable way to do this (if there is any), but you could probably check for the Zone.Identifier. I'm not aware of a way to this natively in NSIS, but you might be able to achieve by parsing the result through the commandline.
Try
nsExec::ExecToLog 'more < "$EXEPATH:Zone.Identifier"'
or
nsExec::ExecToLog 'dir /r "$EXEPATH"'
I've also found several Powershell (and VisualBasic) scripts that allow interacting with Alternate Data Streams, but personally I'm not a big fan of using third party scripting languages.
Assume a Visual C++ solution that outputs several executables. These executables are meant to be run in a certain order and with certain parameters -- and for this purpose there already is an ant build.xml script.
What would be a decent approach to integrating this ant script with VC++, such that the ant script will point against the recently output executables (.\Debug and .\Release folders) and ideally could be run directly from VC++, and dare I say with remote debugging.
I was thinking of using build post-events that populate a build.properties file with the output location of each executable, and let the ant script use this .properties file.
Any help on the matter would be great.
I'm not sure if there is a good answer for this. Perhaps you are not asking the right questions. From C++ you can launch anything, including scripts. I'm not sure what you mean by VC++ integration.
The generic answer would be:
save the output locations somewhere, doesn't matter where (file, registry, environment variables etc.)
retrieve them in the script before use
But depending on what you need, you could also try:
Output the same executables in the same folder structure. This way you can use relative paths.
Use a post-build event which copies the script in the output folder and make it use the relative path.
Instead of a script you can also try handling everything from the first EXE. Instead of an ANT script it could use a configuration file which specifies execution order and parameters.
I would like to control a subset of files and only allow some of them to be installed if run with a command line switch for instance.
Is this possible?
For example
if (some condition)
install full set of files
else
Install other set of files
Alternatively I can just run another installer but then I have to pass the file/path location to that second installer. There is also the issue of bundling that second installer with the first one. I think that part is not that difficult though
Yes, it is even rather easy. There are several ways to do this, all of which depend on Pascal scripting.
Method 1
You can use the GetCmdTail, ParamCount, and ParamStr functions to obtain the entire or parts of the command-line.
Then you can use the Check parameter on separate files. Hence, each file will be installed if and only if the called function returns true.
I want to make a "standard" install for external use, but I also want to use the same script and tell it (with a command line param perhaps?) to include another set of files (PDB files for debugging) for our lab installations. (And make a totally different install exe)
How can I do this? Is it possible?
I don't see how to set this in the [Files] section (conditionally add files based on some value/param)
Note – this is not for allowing the user an option DURING the install. I want a build-time option to set in my hudson build or batch file.
I suppose I can just create a separate installer for the pdbs, but I'd rather just have one file to do everything.
You can simply use
#ifdef DebugVersion
File: *.pdb ...
#endif
and then call the Inno compiler like this:
iscc.exe -DDebugVersion ...
I'd also add something like this so you get different output file names:
#ifdef DebugVersion
OutputBaseFileName=mysetup-dbg
#else
OutputBaseFileName=mysetup
#endif
Note that you'll probably need the InnoSetup precompiler for this, which, for some inexplicable reason, is not part of the default InnoSetup package. The easiest way to get it is to get the "Quick Start Pack" from the InnoSetup download page.
The answer is simple: create two files for each release, but put the common stuff in a third file and #include it in the other two.
http://rickborup.blogspot.com/2006/09/inno-setup-include-directive.html