I use Installshield 2010, a Basic MSI Project.
Is there a way to use RemoveFiles action to remove files from RemoveFile table after InstallFinalize?
I have some files included in installer's components. I use those files to configure other files and after InstallFinalize I want to remove them.
I read about RemoveFiles action and I have noticed that the action is running before InstallFiles.
Is possible to change that or recall the action? How?
Thanks for your time!
If you have temporary files that are only needed during the execution of the installer put them in the Support Files view not components view.
InstallShield has a table ( ISSetupFile ) and related custom actions that will extract these files to a temp directory and assign it to the [SUPPORTDIR] property. It will clean this up for you at the end of the install also.
That way you won't be fighting against MSI trying to get it to install and uninstall something during the install.
No you cannot move the RemoveFiles action after InstallFinalize. As the MSDN documentation states, it must be scheduled before the InstallFiles action.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371199(v=vs.85).aspx
I would recommend using a custom action to perform the cleanup.
Related
I need to modify the installation behavior of a MSI setup for "IBM i Access for Windows". The setup was created using InstallShield. During the installation the setup triggers two other MSI installations through "chaining". The parameters passed to MSIEXEC.EXE to execute those two installations get loaded by a custom action from a DLL that is included with the installation. The parameters end up in a MSI property.
I want to change the value in that property to manipulate the command line before the chained installation gets launched. Is this possible? If so, how? I have no problem to create an external DLL that reads and modifies the property, but I am at a loss on how to integrate this with the existing installation -- which tables do I have to modify and how, where should I put the DLL, ...
EDIT 1: To clarify this: I want to modify the parameters passed to the chained MSI installations. They are independent from the parameters I pass to the main installation and are loaded from a DLL that is part of the installation.
EDIT 2: I have uploaded the plain MSI + the relevant log file. I start the main installation with "/qn" to suppress all messages. That works without problems, the chained installations get executed without visible prompts. The problem arises when uninstalling the software (again with "/qn"). The remote custom action gets loaded from a DLL (line 6417):
MSI (s) (10:28) [09:00:45:643]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIA4BD.tmp, Entrypoint: ISChainPackages
The command line loaded from the DLL specifies to call MSIEXEC.EXE with the parameter "/qb" instead of "/qn" (line 6958):
MSI (s) (10!60) [09:00:46:033]: PROPERTY CHANGE: Adding IS_CHAINER_POST_COMMANDLINE property. Its value is '/l"c:\temp\IBM_iAccess_7.1_Uninstall.log" /qb /x{CCA40632-843E-48C6-B14F-E1070015D87C} ...
And because the MSI installer has a lock on a file a messagebox pops up triggered by the uninstallation of the chained MSI (line 44046):
MSI (s) (10:C0) [09:01:05:553]: RESTART MANAGER: Did detect that the custom action server with process ID 2352 holds file[s] in use, so a reboot will be necessary.
MSI (s) (10:C0) [09:01:05:553]: Note: 1: 1610
MSI (s) (10:C0) [09:01:11:224]: RESTART MANAGER: The user chose to go on with the installation, although a reboot will be required.
The setup must update files or services that cannot be updated while the system is running. If you choose to continue, a reboot will be required to complete the setup.
The installation files for version 7.1 of this software are no longer available on the IBM website. Only the current version is, and I have not looked into whether the problem still exists with the latest version or not as I have been asked to package v7.1 by the business department.
One approach to this problem would be to create a new Custom Action that executes VBScript code stored in the Binary Table and place the new Custom Action right after ISChainPackagePrepare. The VBScript code will read the value of IS_CHAINER_POST_COMMANDLINE and replace it as specified in the Replace() function
The VBScript Code could look like this:
Option Explicit
Function ReplacePropVal()
dim propvalue
dim newvalue
propvalue = Session.Property("IS_CHAINER_POST_COMMANDLINE")
newvalue = Replace(propvalue,"/qb","/qn")
Session.Property("IS_CHAINER_POST_COMMANDLINE") = newvalue
End Function
You want to give your new Custom Action a Type of 6 to indicate that your Custom Action data is stored as a VBScript in the Binary table. Your Custom Action Source is a reference to the Name in the Binary Table. The Target value of your Custom Action will need to be the name of the VBScript Function which is ReplacePropVal in this case
Afterwards, you place your new Custom Action in the InstallExecutionSequence table using the same name for it as in the CustomAction table. Also make sure to give it a higher Sequence value as ISChainPackagePrepare. I would recommend placing it right after by incrementing the Sequence value of ISChainPackagePrepare by 1.
After you've changed the tables and generated a new transform, just run the package with the new transform being applied by specifying its path in the TRANSFORMS public property and your property value should be changed.
I think the ideal approach here would be to transform the chained package definition. The UI level (documentation) is stored in the first two bits of the Options column of the ISChainPackage table, so all your transform should have to do is alter that value. In particular, you can change those bits from ecoUIBasic (0) to ecoUINone (1), which should be as simple as adding 1 to the current value. Also available are ecoUIReduced (2) and ecoUIFull (3).
If ISChainPackage.Options is altered correctly, the desired IS_CHAINER_POST_COMMANDLINE will be generated for you, and you won't have to add a secondary custom action to alter the /qb to /qn afterward. (Kudos to sevi for suggesting that functional workaround.)
If this is an Advanced or Suite UI Setup.exe, please check that
link for how to pass a property.
Package Database Entries (Software Re-Packaging tips for iAccess and other software):
https://www.itninja.com/company/browse/i - look at the IBM entries
IBM i Access for Windows
IBM iAccess for Windows 7.1
How to perform silent upgrade for IBM I Access for Windows 7.1?
Making a silent package for IBM i Access for Windows 7.1 with latest patch
Approaches: What does this DLL custom action do? Does it create a license key? Often these things have been found and solved many times before. To check for this, I usually use these approaches to find solutions:
File Extraction: try extracting files from the setup and look for help files that describe proper deployment. "Large Scale Deployment.chm", "Installation Command Line Parameters.chm", etc... or ready-made transforms or command line file samples (Install.cmd).
Deployment Sites: Check https://www.itninja.com/company/browse/i (Software Re-Packaging tips - look at the IBM entries. Several entries that look relevant, here is one).
Forums: inspect their support forums or online support - if available.
Phone: get on the phone with the vendor. Sometimes very helpful, often a waste of time. Ask for deployment relevant information sent from support. Do this if you have a support agreement?
See section on file extraction below.
Setup.exe Switches: I have a similar or related answer here, where I also mention setup.exe command line switches: Silent run installer (.exe) with parameters on Windows.
Logging: If the custom action does not create something dynamic (unique license key, machine locking identity, etc...), then you can try to find what was generated by logging the setup and looking for the command line used in the log file. Mock-up sample:
MSI (s) (AC:00) [00:00:00:00]: Command Line: TARGETDIR=C:\ SHORTCUTDIR=C:\Documents and Settings\All Users\Start Menu\Programs\Test ACTION=INSTALL
File Extraction: Is this an Installshield Suite project? did you extract the embedded files and MSI files first?: Programmatically extract contents of InstallShield setup.exe.
What is in a Setup.exe?: Installshield setup.exe files can be lots of different things (explanation of different setup.exe flavors): Regarding silent installation using Setup.exe generated using Installshield 2013 (.issuite) project file.
Links:
Extract MSI from EXE
What is the purpose of administrative installation initiated using msiexec /a?
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.
I've managed this in Wix but my colleague wants to replicate it in Installshield 2013 Express. We have found the 'custom actions' section in Installshield but we cannot see where we can make it run after Installfinalize, it needs to come after copyfiles AND have Execute="immediate". All of the options after copyfiles have Execute="Deferred".
In Wix I have a VBScript which reads the MSI Session.Property("OriginalDatabase") and then uses this to write to some config files which are installed by the MSI. The point being that if we rename the MSI then the config is adjusted to reflect the MSI filename.
I would have posted a screenshot of the IS custom actions UI but I need '10 reputation' to post images - So the link to the image is -> Here
Two possibilities here....
1) Since you say it's MyFile.cfg I'll assume it's not .INI or .XML format. In that case, use the InstallShield Text Files Changes view to author a search and replace on the files. The InstallShield custom actions support UAC and Rollback so you'll be good to go there. You will probably need a very simple InstallScript custom action to read the OriginalDatabase property, parse out the part you care about and assign it to another property. Then use that property in the Text Files Changes view.
2) Why have the entires in the .cfg file at all? What application reads these values? Refactor that to not need the cfg files. Windows Installer exposes an API that allows you to query the installer service for information related to installed products. You can ask MSI what the MSI name was for an installed application and then use that information for whatever you need it from. Put the logic in the application and simplify the deployment story for a more robust installer experience.
You are going about this all wrong. Custom actions that modify the machine state should always be deferred and scheduled between install initialize and install finalize. Failure to do so will break in an UAC environment and also not support transactional rollback on failure.
Are these XML files? I'd use immeadiate custom actions scheduled just after installinitialize to emit temporary records into various MSI tables. The concept is to leverage DuplicateFiles to clone the file to a name based on the MSI name. You'd also have some work if you need to modify the files. Done correctly and your installer will still have full rollback functionality and work in an advertised / UAC scenario.
Also, VB/JScript custom actions are not reliable.
Using Installshield 2010 and Basic MSI project.
I have an exe that was previously installed by my installer. That exe needs to be running during an installer upgrade. Is there a way to guarantee that the installer won't try shutdown the process? Basically, I would like the behavior to be : If file doesn't exist, lay it down, otherwise ignore it.
I have made the exe a key file in a component and set it 'Never Overwrite' to true. Should this give me my desired behavior ?
Never Overwrite will be used by future installers to determine if the file will be overwritten or not by other MSI packages. Basically, this attribute should have been set for the installed EXE.
A good approach is to use a file search to determine if the EXE exists. The search property can then be used to condition the new component.
Windows Installer doesn't automatically close applications, but it does show a FilesInUse dialog which offers this option to the user.
hii,
i made a bootstrapper for my msi to check and install the prerequisites..and when i click the
setup.exe file it smoothly check and install..there is no problem in it..
*)For now i use GenerateBootstrapper and bootstrapperFile to create bootstrapper.
But my problem is this that when the prerequisite are installed they use there own install window.but i want to provide single installation feel..
i want to run every prerequisite file in my own customized UI ..
i want to customize the Ui of them.How can i do this?? can anyone help me out??
thanks.
as far as I can tell currently there is no way of doing it with wix only.
Butwix3.5 should contain sth called Burn http://robmensching.com/blog/posts/2009/7/14/Lets-talk-about-Burn