I have built an installer using WiX which lets the user upgrade a current installation to the next version and change the location of the install folder. This works when using the .msi file, but when running this silently using msiexec, my setting of the INSTALLDIR is overwritten later on in the installation process.
I have had a look at the logs and it is being written over with the current install directory. I have a property which searches the registry for the current install location and sets the INSTALLDIR to that value.
I guess in the .msi UI value, things are running in the right order, but with the silent install, they're not.
MSI (s) (A0:90) [09:47:34:315]: PROPERTY CHANGE: Modifying INSTALLDIR property. Its current value is 'C:\SpecifiedInSilentInstall'. Its new value: 'C:\CurrentInstallDirectoryFromRegistry\'.
Is there a way of specifying the order in a CustomAction or something?
If you are using a custom action like this
<CustomAction Id="SetInstallDir" Property="INSTALLDIR" Value="[YourInstallDir]" />
you can time it in your <InstallExecuteSequence> section like this
<Custom Action="SetInstallDir" Before="CostFinalize" />
Here you can time your events with Before and After. These events follow a specific order (taken from FIREGIANT)
AppSearch
LaunchConditions
ValidateProductID
CostInitialize
FileCost
CostFinalize
InstallValidate
InstallInitialize
ProcessComponents
UnpublishFeatures
RemoveShortcuts
RemoveFiles
InstallFiles
CreateShortcuts
RegisterUser
RegisterProduct
PublishFeatures
PublishProduct
InstallFinalize
RemoveExistingProducts
For the property INSTALLDIR it is important to set it at the right event to take effect (whatever your needs are). For me Before=CostFinalize changes the path to the one I want.
Related
I ran installer which contains custom action:
<Custom Action="renameIndex" Before="InstallFinalize"></Custom>
this just run one bat file which was previously installed on drive.
In never version of this installer both that custom action and bat file were removed from installer.
In the installation logs i can see that bat file is removed:
MSI (s) (A8:5C) [13:08:27:790]: Component: indexSCO.bat; Installed: Local; Request: Absent; Action: Absent
MSI (s) (A8:5C) [13:08:28:062]: Executing op: FileRemove(,FileName=indexSCO.bat,,ComponentId={EC857BEC-50CA-4DE7-B80B-D1DF4AC37CF5})
but the Custom action is still being called even though it was removed from InstallExecuteSequence
Is there any link that causes that custom action to be called because if existed in previous version of installer or I should search for mistakes in installer file?
While upgrading to newer version from previous one, by default uninstallation of previous version is invoked first. This will be launched from installer cache(C:\Windows\Installer). As the above custom action had no condition in previous version, it was triggered during uninstallation.
Once the uninstallation is completed by RemoveExistingProducts action, newer version msi InstallExecute sequence will be triggered and the new changes(removed custom action) will come into play.
We found some uninstallation issue on already released msi which is creating issue during upgrade of higher version.I need to modify few custom action conditions so that it doesn't run while msi uninstallation. In order to this, transform file is generated with updated condition. However, I am not sure how to pass this during uninstallation? user can trigger uninstall from Add or Remove Programs.
Minor upgrades are not option for us as it requires release of new msi.
The locally cached MSI within the Windows folder is a transformed version of your original MSI database, if you installed it together with the MST.
Your custom actions added by MST, if they have no condition set, are always run (on install, repair and removal).
If you want to run your action only on uninstallation, set this as the condition: REMOVE="ALL" or inverted NOT REMOVE="ALL" if it should NOT run on uninstallation.
Try to place your custom action in the Table InstallExecuteSequence between InstllValidate and InstallInitialize or after InstallFinalize
You don't need the MST during uninstallation.
I want my custom action to be executed after the complete installation is been done. Went through so many sites but didn't get it work.
<Binary Id="DepTypeCustomActionBinary" SourceFile="$(var.SolutionDir)\Proj.Setup\DepCustomAction.CA.dll"/>
<CustomAction Id="CheckDepType" BinaryKey="DepTypeCustomActionBinary" DllEntry="CustomAction1" Impersonate="no" Execute="deferred" Return="check" HideTarget="no" />
<InstallExecuteSequence>
<Custom Action="CheckDepType" After="InstallFinalize">NOT Installed</Custom>
</InstallExecuteSequence>
Above is my code and I am getting below error:
CheckDepType is a in-script custom action. It must be sequenced in between the InstallInitialize action and the InstallFinalize action in the InstallExecuteSequence table
I'll just add a short answer rather than adding too many comments. I am not sure what dscrt40.dll is doing - is it a file you use during installation for some runtime dependency? I wouldn't recommend installing your own files into a pre-existing folder - if that is what you are doing.
I suppose you could try to use the RemoveFile construct to have the Windows Installer engine remove the file in question on install, this should prevent the need for a custom action. You must not do this if you install the file you are removing via a Windows Installer component first - then self-repair is likely to kick in to put it back afterwards.
A custom action that makes changes to the system can not be sequenced after InstallFinalize - the database change transaction ends with InstallFinalize, and you no longer have elevation for the custom actions that follow after InstallFinalize (immediate mode custom actions can be inserted, but they will fail unless you are running with admin rights - don't try it - it is impossible to rely on). You can only insert change custom actions (deferred custom actions) after InstallInitialize and before InstallFinalize in the InstallExecuteSequence.
You should be aware that files will be present on disk after the action InstallFiles has run (technically on the second run through the InstallExecuteSequence - the first run - immediate - just creates an execution script, the second run - deferred - executes the script), so you can in principle delete files after this action has run, but it doesn't really make sense to do so.
Why do you need to delete this file?
Do you install this file yourself or is it a pre-existing file?
Our product was installed via InstallShield Setup over the years. I changed the installation to MSI (WiX) this year. Now the MSI should clean up the directory, which remains the same.
One custom action in the MSI I implemented to start the uninstallation of the old product:
<CustomAction Id="UninstallIS" Property="QtExecCA" Value=""[WindowsFolder]IsUn0407.exe" -f "[ProgramFilesFolder]\company\product\Uninst.isu"" Execute="deferred" />
<CustomAction Id="QtExecCA" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="ignore" Impersonate="no" />
After the removal of the old product there are temporary files and some subdirectories that are different from client to client and are unknown to the InstallShield Setup, so I would try to delete them via the MSI.
Keeping the UAC in mind, I think that I can't use command-line commands to do this also the 'Remove File Table' is not useful here (to much unknown files and many directories).
What is a possible way to do this?
Thank You for any help!
You can use a Deferred custom action which has Impersonate flag set to "no". This way it will run under the local system account with full privileges.
The custom action can use custom code (for example an EXE or DLL) or a command line.
Please note that deferred custom actions can be scheduled only after InstallInitialize action in InstallExecuteSequence.
As a side-note, make sure you thoroughly test it. Deleting files from the target machine is very dangerous. You never know what you may end up deleting.
I have something like this:
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallValidate"/>
</InstallExecuteSequence>
Since one of the uninstallation fails i need to execute a Custom Action to solve the problem BEFORE RemoveExistingProducts. Something in the lines of:
<CustomAction Id="FixStuff" .. />
<InstallExecuteSequence>
<Custom Action="FixStuff" Before="RemoveExistingProducts" />
<RemoveExistingProducts After="InstallValidate"/>
</InstallExecuteSequence>
This of course doesn't work since Custom Action cannot be before InstallInitialize. I'd really like to remove existing products between InstallValidate and InstallInitialize, but i'd like to execute FixStuff before removing existing products.
Is it even possible to do that?
Unfortunately you cannot run an elevated custom action before RemoveExistingProducts with your current configuration.
Some possible approaches would be:
Move RemoveExistingProducts right before InstallFinalize. This solves the custom action problem, but other problems may occur since this approach has many restrictions (the components need to maintain their names and GUIDs between versions, your custom actions should be aware that the upgrade is performed at installation end etc.).
Create an EXE bootstrapper which fixes the old installer before launching the new MSI. This bootrapper can require Administrator privileges through a manifest:
http://msdn.microsoft.com/en-us/library/bb756929.aspx
Repair the broken MSI by using this method:
fix the problem in the old MSI
create a BAT or EXE bootstrapper which recaches it through this command:
msiexec /fv <path_to_msi>
distribute this MSI as an update before your new package
When your new package runs RemoveExistingProducts, the old cached MSI should be fixed and it should uninstall correctly.