I'm having installshield project and I several powershell custom actions.
The scripts change the file system (extract zip files, copy files, install packages, etc).
I wonder where in the install sequence should I put them?
I looked at the guilde here but they don't cover it.
I tried to put it in the execute sequence after "InstallInitialize" but that made my scripts behave weird (some of the cmdlets work and some don't).
Then I moved them to the UI sequence after "ExecuteAction" and that seems to be working fine but I read somewhere that I shouldn't put in the UI sequence any scripts that change the file system..
What is the right place?
Thanks
Events that change the system should not be placed in the UI sequence, one reason is that there isn't anything preventing your user from skipping the UI sequence.
During the execute sequence, you cannot install another MSI package. Some installers may look like a .exe but have a bundled MSI. If your goal is to handle installing prerequisites, then you need to possibly use the InstallShield Suite/Advanced UI install. That has a method of managing multiple install prerequisites. I suspect that the problem you encounter is that some of those packages you try to install have imbedded MSI installs.
Related
I've been to stackoverflow.com many times, but this is my first time posting here. I'll try to be as specific and to the point.
I'm in the process of converting all my PC discs into digital .iso files and there's a few games I have that are multi-install discs.
Recently I've started using Inno Setup and so far I've had a lot of success consolidating multi-disc installs into a single program executable.
The one I'm currently focusing on is the Battlefield 1942 series. It requires initial installation, multiple expansion installs, plus a major patch, plus the installing of a mod that takes multiple steps.
My question to the community is how would I pack all of the above files into one executable and have them install everything in order? If it can be done through Inno, I'd like to try that. Or if you suggest another program I can always take time to try and learn it.
I've tried making a batch file for this a while ago but it ended up kind of clunky and I really didn't like the way it turned out.
Also, is there a way to insert check boxes into Inno to choose what executables run? (this part of the post isn't as important as the above request, just kind of a bonus if possible).
Really looking forward to the community's response on this!
One approach you can follow is to create a installer of installers, where you just pack the installers you have now and at installation time run each in the precise order you do now to get your fully installed and patched game.
That way, you don't have to learn each file/registry key or other settings each game have, and the risk of failure if you forget to include something vital to it.
What you have to do in order to do that properly, is to learn if the current installers accept it's own configuration from command line parameters or text files (many installers do it, for example the /silent or /verysilent command line parameters to run on the background). Once you do, use the [run] section of your script to launch each installer passing the parameters via command line or pre-made text files, or even you can create a text file or command line parameters on the fly using the [code] section with the built-in pascal script.
If your installers don't accept parameters, you can even reach your goal to keep all in one single exe file which you can run and then configure each individual installer as it launches.
Your question is overly broad to include here a working example, but you can find guidance by studying the scripts in the samples directory.
As for your final question
Also, is there a way to insert check boxes into Inno to choose what executables run?
You can use the [run] section to let the user select what to run at the end.
Or you can use the [tasks] section to create different sets of files/configurations.
A final word is to check the available flags for your install script entries, for example, deleteafterinstall to cleanup individual installer included among your [files] entries, or the [uninstallrun] section to give a unified uninstaller also.
In my opinion, if the final result should be fully patched version with mod installed, you should build new installer that will contain that fully patched game with mod.
You can do it easy way to find out what is changed/added by each patch, addon, MOD.
After installation of each thing (addon/mod/etc.) make a backup copy of the installation folder and check the registry entries.
Then just compare folders/directories and filter out specific files for each patch, addon, MOD.
At the end you will be able to add each addon and MOD as Components (files and registry entries) - that will create checkboxes in the Components Selection Wizard Page.
Easiest way:
For External Installers/3rd Party Apps at the end of installation more info to be found here: http://www.jrsoftware.org/ishelp/index.php?topic=runsection
I would like to know how can I detect if help file is contained in setup file for windows platform application (msi or exe). Is there any method to get this information without installing the software first ?
Of course setup file can be created by many setup makers like innosetup, installshield and so on. So I wonder if there is some universal method to solve this.
For an MSI based install it would be very easy. For example you can use the Microsoft.Deployment.WindowsInstaller interop via C# to open the MSI as an InstallPackageClass then access it's Files collection to see if it contains the file you care about.
For a Non-MSI based install, there is no universal way and in most cases, no way period. See, that's kind of the point of MSI: to have a standards based package rich in meta data to be able to see what it's doing. When you do some proprietary script driven installer you lose that openness.
If it's a MSI file, open it up using Orca, and you can view file names.
For both of them, you should be able to do an administrative install, which would extract the files, but not register anything. Depending on where the exe came from, doing an administrative install changes, since each vendor(installshield, innosetup, etc) has their own way to run an administrative install.
for a MSI it's simply
msiexec /a <msi_filename>
For an exe you'll have to look up how to pass the /a argument.
I would like to build a setup, or something like that (1 file), to deliver a single file to a target system. Plugin for an application, installable to users AppData folder.
After some research I'm still not sure in which direction to look. I can create the setup project with Visual Studio 2010, but all of the options so far seem to be way too heavy or have some flaws.
SetupProject stubbornly wants to create an application folder which I don't need, and complains about installation to user folder. Cab doesn't seem to offer automatic install, oneclick is not available for the project, etc.
Is there an easier setup technology I could use?
Requirements:
Install -> Copy 1 file to a folder
under %userprofile%\3rdpartyapp\ if
it exists (xcopy).
Uninstall -> Delete the file and also
one folder with custom settings
(rmdir \s).
Distribution -> Free for commercial
use.
Maybe I should just pack the file in self extracting c++ exe?
It may be overkill for one file, but I like InnoSetup for creating setup packages. Check it out, and see if it suits you. It is very easy to use and deploy.
Take a look at WiX toolset. It allows creating MSI-based installers, and the installer could be quite simple:
Search for %userprofile%\3rdpartyapp;
Copy the file into it, if it exists;
Fail install or maybe create it, if it does not exist.
Uninstall would be very simple: it would need to remove the installed file. To remove a subfolder of 3rdpartyapp, you can use RemoveFolderEx element.
MSI registers the installed app with Add/Remove Programs Control panel. Uninstall is handled by Windows Installer service, therefore you don't need to copy any additional files or programs to support uninstall.
I think any setup technology is too heavy for one file. I'd go with creating a simple application that would extract the file from its resources stream and copy it into %userprofile%\3rdpartyapp.
Uninstall is trickier: there should be something that can handle the uninstall process. It could be a batch or script (js, vbs) file stored somewhere in user's profile, another simple application or the same one. (Installation process can also be handled with a script.)
I am developing a package using Installshield 2008 Primer Edition and Project type is Installscript MSI project.
The problem I am facing is during installation I am installing some of the files to the following location C:\Program Files\Company\SystemFiles from this location I am copying and adding the set of files into System32 folder, it contains DLLs and OCX files, copying into the System32 folder has been done using Installscript.
Due to this during uninstallation, the installed file is getting removed from System32 due to this other dependent application which requires the same set of DLLs have stopped working.
I have approached Installscript to copy files from ProgramFiles to System32 Folder rather than using built-in options because we have an issue during the upgrade in order to avoid that I am using Installscript.
Even I have tried several workarounds like setting the file attributes after file copies to System32 using Installscript like FILE_ATTR_SYSTEM which sets the system attribute but still files are getting removed during uninstallation.
Any idea how to give file attributes as PERMANENT or SHARED; will this help, and if it will, then how can I set it using Installscript?
I have 2 ideas
1)I think you can use SHARED option as this wont remove the files while uninstallation.
2)Also when i was facing similar issue , what i did was putting all the required files in the installation directory itself so that while uninstalling only the installed files will be removed.(I know this is not a best solution)
(NOTE:I have worked on Install shield some 6 years back and so remember only certain things)
You can also disable logging from Install Script. This will make the installer "forget" that it installed specific files groups or features.
You should make sure to enable logging once again after you have copied the files that you want to permanently leave on the system.
If you don't remember to enable logging after you have disabled it, your uninstall process may not work correctly.
Syntax is as follows:
Disable(LOGGING);
//Add code to copy your permanent files here
Enable(LOGGING);
For InstallScript projects:
To prevent the files in a particular Component from being removed during uninstall:
1-Select the Components view from within the Organization folder.
2-Select the component that contains the files you do not wish to remove during uninstall.
3-Change the "Uninstall" property in the right pane to a value of "No."
For MSI Projects:
To prevent the files in a particular Component from being removed during uninstall:
1-Select the Components view from within the Organization folder.
2-Select the component that contains the files you do not wish to remove during uninstall.
3-Change the "Permanent" property in the right pane to a value of "Yes".
I see this is an old question but I just came across this. Seems to be a common problem. One good solution is to stage the files to a private directory mostly program files and then have a custom action do the copy and register (ocx etc). Installshield remembers what it copied so it tends to remove them. Do not disturb anything else like logging (my recommendation). Set conditions on the custom action so that it doesn't run during Uninstall.
Although sometime back I did another weird implementation which only programmers are used to doing.. Packed the files as resources and created my own code to extract and deploy (Something that Process Explorer kind of tool does). There were certain use cases that warranted this kind of implementation. But again this is complicated and obviously reinventing the wheel. Unless you are good with C/C++ and Windows API this would be difficult. I would still suggest you stay away from this kind of implementation because it is also considered a "virulent behavior". Yet, so far I never got warnings from the Anti-malware products.
My installer requires there be two files in the same directory in order for it to install.
The installer (.msi file)
An organization specific config file that the installer copies. (This file is customized by the organization and then distributed to it's end users).
Since there are two files, the file has to be distributed as a zip file. Which presents the issue of if a user tries running the .msi without actually extracting the zip... only the msi file gets extracted. I am able to detect the issue in the install process and tell the user they need to unzip the file... but you know how noone actually reads error messages.
So, I'd like to make it more foolproof and so i was wondering if there was a simple tool that i could let my customers (ie the organization) be able to make modifications to the config file and when finished create a .exe file which when clicked would extract to a temp folder and then run the msi. I know there are solutions for this which require commercial software. I'm wondering if a simple freeware tool exists that can do this.
Edit: Accepted Solution Notes:
The one issue i ran into is the iexpress wasn't designed to be used for .msi files. As a result on the step that asks you for the Install Program. It's a combo box which if you had added a .exe file in the previous step could just select the .exe file from. Instead you have to manually type in
msiexec /i yourinstaller.msi
I was very pleased to find such a simple solution that's built in to windows. The only way this could be better is if it allowed for wildcards so that your iexpress project would be able to handle changes in the msi file's name which occur with each version. And defaulting the Install Program to the .msi file. These minor inconveniences are offset by the fact that end user wouldn't need to install any new software to create the package so I have stopped looking for other tools.
You could try using iexpress.
It enables you to package up a set of files which can be extracted, with the option of running an installation command automatically after extraction. It also has options to enable you to prompt users about things, show a EULA, restart the computer, etc..
I believe it comes as part of Windows (part of IE?) - try running iexpress.exe from the run dialog to get the UI.
The Wix project has a bootstrapper and packager for dealing with this kind of thing.
I've used wix a lot but haven't really looked at the bootstrapper/packager much - last time I had a quick look it wasn't really usable but that was a long time ago so it may be better now.
I'm guessing that the config file is something like a properties file, and that you want users to set the values of the properties "foo" and "bar". You don't need a separate tool to update the file.
I would do this:
Put one or more dialogs in the install that ask the user what the values of foo and bar should be, and set a couple public properties accordingly.
Write a custom action that writes the config file out to whatever location you want, including whatever values you want for foo and bar. This would be pretty easy in vbscript.
Put the custom action somewhere in the execute sequence (ideally as a deferred execution action, since you're making changes to the system).
Add an entry to the RemoveFile table, so the config file is removed on uninstall (assuming you don't want it to be left behind.)
Add an entry to the LaunchCondition table, to prevent users from doing a silent install. Or if you want silent install to be allowed, make the names of the public properties that hold the config data known, and make them part of the LaunchCondition. You would block "msiexec /i myapp.msi", but you could choose to allow "msiexec /i myapp.msi FOO=Something BAR=SomethingElse".