- Advanced Installer Custom Action
- Windows Installer Setup With Custom Actions
- Windows Installer Custom Action Data
- Windows Installer Add Custom Action
I am designing a windows installer project using WIX. Now it fails in the installation, because the Commit custom action won't get executed, which is caused, weirdly, because a scheduled following. Is possible any body tell me what is the flow of actions that are followed by the Windows installer internally This is a good description of windows installer sequencing. Trying to run.bat file using windows installer custom action. The folder gets copied and kicks off the install. Adding the batch to MDT, the folder copies but no-go on the install running. Immediately after the copy, about 3 seconds, I get the white Final Summary screen with zero errors/warnings. Regardless of the syntax - quotes, no.
I am creating a setup project with Visual Studio Installer. I need to backup some files by a custom action, if the user installs a newer Version over an older one. The problem is, that i have only the 'Install' hook to start the custom action, but this is too late as the newer files are already installed at this point. Darwin Transform and Its Application in Windows Installer Custom Actions. In some cases, using Windows Installer API functions does not provide information about certain specific elements of a Windows Installer package. Let us consider the following scenario. During the initial installation, the setup disables some features (setting their. I have written custom installation form (code in C#), which is invoked through the Custom action (of windows installer.msi). I have a cancel button in the form. Now i need to rollback the installation process (Remove all files added / copied, and also the registry entries made), when i click. If you want to undo (rollback) what the custom.
I’m currently working on a project where I’m creating a custom HTTP module for a customer. The module is to be used with an existing commercial product. Since the custom HTTP module is working with an existing product, the process of installing it would need to make significant changes to the web.config file of the existing product, plus be able to remove those changes during a subsequent uninstall.
I hadn’t worked with Windows Installer XML (WiX) projects before so this was a perfect opportunity to get up to speed.
Creating a Setup Project and C# Custom Action Project
Once you install the WiX toolset you’ll be able to create a new Setup Project from Visual Studio as shown below.
![Custom Custom](/uploads/1/2/6/5/126582701/239563471.png)
After creating the setup project you’ll have a Product.wxs file that defines your setup. I won’t go into details about the general process of authoring this file as this is covered in detail in the online WiX tutorial. Once we’ve created our setup project, we’ll need to add a C# Custom Action Project to our solution (you can see this project template option in the above screenshot as well). Within the custom action project you’ll have a new CustomActions class that looks like the following:
This is where you’ll write the code that you want to be executed when the custom action method is called. Any method that you want to expose to the setup project must be a public static method that is annotated with the CustomAction attribute and has the following method signature.
The Session parameter passed to the method is the object that controls the installation process. Among other things, the Session object allows you to write output to the installation log file and gives you access to global properties for passing data (we’ll use this later).
So in my particular instance I needed to write a custom action that would perform various updates to the existing product’s web.config file as part of the install. WiX provides what’s referred to as a Standard Custom Action library for manipulating XML files as part of an installation. However, after reviewing the on-line content and some examples this proved to be far too cumbersome for my needs.
So my custom action method ultimately looked similar to the following:
The code snippet shows what could be argued as a standard boilerplate approach for custom actions. Logging the entry and exit of the custom action, performing the configuration step necessary and handling an unhandled exceptions to make sure they are logged to the output correctly.
Compiling the custom action project will generate two DLLs. The additional DLL, $(TargetName).CA.dll, provides a format that is callable from the MSI engine. Therefore, this is the DLL that we want to reference from the *.wxs file in the setup project. To do that, we add a Binary element within the Product element that was generated in the *.wxs when the setup project was created.
In the snippet above, I’m referencing the *.CA.dll relative to the setup project (which is in the same solution). I’m also indicating that I want to base the version of the *.CA.dll on the current build configuration of the setup project using the $(var.Configuration) syntax. That way, if I build a debug version of the setup project I get a debug version of the custom action and a similar result for a release build.
Along with the Binary element, we’ll also need to add a CustomAction element to reference the Binary element’s Id and indicate the entry point that we want to execute. This should look similar to the following:
In the above example, notice that the BinaryKey attribute matches the Id attribute of the Binary element we previously added. Also note that the DllEntry attribute references the method name that was decorated with the CustomAction attribute in the C# code.
Adding the Binary and CustomAction elements by themselves however still does not result in the custom action actually being executed. To include the custom action in the installation process we need to add an entry to the InstallExecuteSequence as shown.
Note here that we’re referencing the Id attribute of the CustomAction element while indicating that we want this action to execute prior to the standard InstallFinalize action of the installation.
Passing Parameters
The last issue we need to resolve is retrieving the location of the existing product’s web.config file and passing it to the custom action. In my case I can use a standard RegistrySearch action to read the install path of the existing product from the registry. The web.config should exist within a well known folder path within the install path. Since the RegistrySearch action will store the root install path to a property, I need a separate CustomAction to build out the full path to the web.config file. As a consequence, I’ll also need another entry in the InstallExecuteSequence to execute this new custom action. These 3 additions are shown below.
The result of the above is that the web.config file’s path should now be in the global property named CONFIGFILE. With the Session object discussed earlier, I can now access this path from within my custom action code using syntax similar to the following:
Now within my custom action method I can open the web.config file and make the necessary edits for my custom HTTP module.
![Windows installer custom action 2 Windows installer custom action 2](/uploads/1/2/6/5/126582701/204348926.png)
Since the web.config edits are performed by a custom action, they won’t automatically be removed during an uninstall. In my next blog post I’ll discuss creating a separate custom action to remove the web.config edits and have it run only during the uninstall of the module.
Custom actions are actions entirely defined by the user. They can be executable files, dynamic linked libraries, Visual Basic scripts or JavaScript files. They can be scheduled at any time during the installation. An installation process consists of two sequences: Installation User Interface Sequence and Installation Execute Sequence.
In the User Interface Sequence only immediate custom actions can be used. It contains a list of Standard Actions starting with Begin and ending with ExecuteAction. ExecuteAction is the one that triggers the execute sequence. At the end of the installation process, the installer returns from the execute sequence in the UI Sequence. It does that in order to execute the actions that may be specified after ExecuteAction. The installation process ends with the ExitDialog.
The Execute Sequence contains a list of Standard Actions that starts with Begin and ends with InstallFinalize. It also can contain all types of custom actions: immediate, deferred, rollback and commit actions.
Advanced Installer Custom Action
In the sequence that starts with Begin and ends with RemoveExistingProducts only immediate actions can be used. The sequence that starts with the InstallInitialize standard action and ends with InstallFinalize will be gone through twice. The first time the installer scans all the actions contained by the Execute Sequence and it creates the installation script used for the actual install.
The second time, based on the installation script, the installer executes all the actions contained by the package only if their conditions were true when the script was built. For example, it will start/stop services, it will write/modify registries, create shortcuts and it will install the files on the target machine.
When the installation script execution is done, the installer returns to the User Interface Sequence in order to display the exit dialog and/or execute any custom actions that may be placed after the ExecuteAction standard action.
As mentioned above, there are four types of actions:
- immediate actions
- deferred actions
- rollback actions
- commit actions
The immediate actions can be used anywhere in the Install UI Sequence and in the Execute Sequence, but for the second one there is a phase where immediate actions can no longer be used. This happens when the installation script is triggered. The immediate actions should not modify the target machine since those changes cannot be rolled back.
The deferred actions, can run only during the installation script execution. The deferred actions should be the only ones that makes changes on the local machine. This is why each deferred action must have a rollback action so that the changes it makes can be undone if the setup fails or is canceled.
Windows Installer Setup With Custom Actions
The rollback actions are used when the application is installed, but something went wrong and the installation must be rolled back. While the installation script is executed, the installer builds a rollback script. After every standard action is executed, the installer adds a rollback command to the rollback script.
Windows Installer Custom Action Data
The commit actions are the opposite of the rollback actions. The commit script is executed after the InstallFinalize standard action when everything ended successfully. Its purpose is to delete the backup files created by the rollback script.
For each of the deferred, rollback and commit actions you have an additional option: With no impersonation. This is related to the current user's rights set by the User Account Control (only for Windows Vista or above) when running the package. A normal user can run a custom action that requires administrator rights only if the “With no impersonation” option is set for it.
Windows Installer Add Custom Action
You can create and schedule Custom Actions in Advanced Installer in the Custom Actions page.