I need to define the {tmp} constant (i.e. the automatically generated TEMP location), so that it always remains the same and does not change each time it is run. Ideally setting it to the root of the users TEMP directory, rather than the automatically created subdirectory (e.g. is-70G7E.tmp):
C:\Users\Username\AppData\Local\Temp
Instead of:
C:\Users\Username\AppData\Local\Temp\is-XXXXX.tmp
Is this possible and, if so, how could it be done?
To expand on the reason for this, in response to comments below, when using InnoTools Tray, it creates multiple entries in the System Tray Notification Area Icons:
This is because each time it is run, it is run from a different {tmp} folder. If I can set this manually myself to be constant and handle the issues of checking for files in use etc it will resolve this issue.
If there is another way to resolve this, then I am open to suggestions.
It's not possible. The creation of random subdirectory in TEMP is hardcoded. There's no way to change it.
See the CreateTempDir function in Inno Setup source code.
You didn't state why you need it to be constant, but a problem may rise if you use a constant folder. What if the folder or files in it are in use? That's why {tmp} varies, and Inno Setup handles it for you.
However, you can use the {%TEMP} constant or the GetTempDir function instead, with whichever sub-folder you like as a constant. You may need to handle its creation and deletion though.
Related
Due to the buggy nature of InstallShield, it is incorrectly modifying my app.config files replacing <clear /> with <clear></clear>
After my app.config file is copied to install path, I want to run a custom action that can scan for all config files and do a standard find and replace.
I don't need code for the find and replace, what I want to know is how / where to put this custom action using Installshield?
Your best bet would be creating a deferred execution custom action and place it near the end of the execution sequence. This will guarantee it would run after the files have been installed.
In the 'Custom Actions and Sequences', Create a new custom action of the appropriate type (depending on your implementation of this replacement action). Set it's In-Script Execution to 'Deferred' and in the Sequence section have add it to the Install Exec Sequence, After ScheduleReboot.
The easiest way to modify config/ini files after deployment of files is the option of INI File Changes or Text File Changes under the System Configuration tab. You can mention the config file location and the replacement changes that you want to perform. Please refer this link.
We have Installshield 2009 for our product. I am trying to muddle my way through it to make some updates (obviously, I am not the original author).
Within, there is a fairly complex arrangement of components and files, plus, there is a script section for some custom work.
I need to accomplish the following, without creating a blank object in the repository.
One of the components needs to create a directory tree (two folders deep).
Within that tree (deepest folder), I need to create a blank file.
Questions:
Do I need to create two components, one for each directory level, or will the tree be created if I specify [INSTALLDIR]folder1\folder2?
I am thinking that the installscript would be the place to create the empty file, based on the CreateFile example in the help. I notice that, in the components page, that, once I typed the value for the Destination property, that a little "tag" of sorts appeared at the start {FOLDER2}. Can I used that tag as an argument to CreateFile and how would I reference it?
Regardless of the project type, I would probably suggest creating the folder structure in the Files and Folders view, and adding the empty file there. It's just simple and you'd be done with fewer chances of error.
As to the questions you asked, neither Basic MSI nor InstallScript projects require components for every folder level on the system. Note that if the folder isn't already there when it executes, the CreateFile approach is unlikely to create the folders for you.
In a Basic MSI project, {FOLDER2} indicates that FOLDER2 is the name of the directory entry, and after CostFinalize there will be a property of the same name that contains its run-time location. You can retrieve it in an InstallScript custom action with MsiGetProperty. In a pure InstallScript project the approach would be a little different, worst case it would be something like TARGETDIR ^ "folder1" ^ "folder2" (my InstallScript is rusty).
I created an installer with innosetup to install an application that consists of two executables. Each of them should go to a separate folder. So I created a custom InputDirPage using the "CreateInputDirPage" function and added two entries to this page, one for each executable
To prevent the default DirPage from showing up I used these parameters in the [Setup} section:
DisableDirPage = yes AND AlwaysShowDirOnReadyPage= no
I wrote functions to extract the Folder paths from my custom DirPage and
this works fine and evrything ends up where it is supposed to be.
BUT: During the installation process Innosetup tries to create the folder set in the DefaultDirName as this folder is the value in the invisible DirPage.
If that folder does not exists and one would need administrator rights to create that folder, the setup will crash.
I worked around that problem by setting DefaultDirName = {pf} in the [Setup] section.
(As the program folder does always exist, I do not get any error messsage for failed creation attempts that way)
Now my questions are these:
Is there a setup parameter that tells Innosetup to completely ignore
the content of the wizard dir page? Because making it invisble seems
no to be sufficient.
Can I set that content or the {app} constant at runtime to avoid the "DefaultDirName" folder from being created?
Yes, there is an option called CreateAppDir.
[Setup]
CreateAppDir=No
I have a code on the server-side(application) that links with the client-side(application).
The user signs-up to download the exe(client-side application).
There must be a unique way to identify the user(client app exe) with the info got from sign-up.
So, one of the information must be attached to exe file during the download.
One of the ways I found is using "Portable Executable".
Is it possible to add string data to exe and later retrieve it?
Is there any other possible way to make the exe user-specific? Or is it possible to add the user information along with the downloaded exe?
Yes, it is potentially possible to modify the exe at runtime to put your own stream. You might put the User Specific information in an existing Resource prepared for this "update". This would be the easiest way to avoid to take care about changing other parameter like size, etc.. Another option would be to put the User Specific information in the overlay of the Exe.
Is there a possibility to add directory (with sub directories) to SupportFiles section in installshield. I have dynamically created content (list of files changes constantly) that I use to support my installation.
Is there any other method to add dynamically whole directory to installation package. I need files from this directory only during installation process. At the end of the installation I want IS to remove these files automatically ?
The ISSetupFile table ( which drives the Support Files pattern ) only supports extracting files to a single directory. There is no way in the UI to tell it to be dynamic although you could have a build automation step that reflects the contents of a directory and wires it up to the table using the automation interface. This still couldn't do sub directories though.
What you probably want to do is creating a self-extracting zip of the files you need as part of your build and add that EXE to Support Files. Then write custom actions that call the EXE to extract the payload to Support Files and another CA to clean it up. Look for the custom action ISSetupFilesExtract and ISSetupFilesCleanup to figure out the best way to do this.
Although I'm late to the party: #BuvinJ mentioned in a comment that you can add directories to "Advanced Files" under "Disk1." In this case, they do appear in the temporary directory (support directory), eg. SUPPORTDIR\Disk1
SUPPORTDIR is a temporary location where the installer dumps files, and cleans them up afterward. An example is C:\Users\<your user name>\AppData\Local\Temp\2\{F6B9B2D6-2A5A-4146-9297-E80A199CB0CB}.
This could be a quicker/cheaper/faster solution to writing custom actions and/or packaging up files by hand in, say, a self-extracting zip file.