Windows File Versioning Rules

At the core of any installer is the actual installation of files. But determining whether to install a file is a complex process. At the highest level, making the determination depends on whether the component to which a file belongs is marked for installation. Once the determination is made that a file should be copied, the process is complicated if another file with the same name exists in the target folder. In such situations, making the determination requires a set of rules involving the following properties:

• Version
• Date
• Language

The installer only uses these rules when trying to install a file to a location that already contains a file with the same name. In this case, the Microsoft® Windows® Installer uses the following rules to determine whether to install.


Highest Version Wins — All other things being equal, the file with the highest version wins, even if the file on the machine has the highest version.


Versioned Files Win — All other things being equal, a versioned file gets installed over a non-versioned file.


Favor Product Language — All other things being equal, if the file being installed has a different language than the file on the machine, favor the file with the language that matches the product being installed. Language neutral files are treated as just another language so the product being installed is favored again.


Mismatched Multiple Languages — All other things being equal, after factoring out any common languages between the file being installed and the file on the machine, any remaining languages are favored according to what is needed by the product being installed.


Preserve Superset Languages — All other things being equal, preserve the file that supports multiple languages regardless of whether it is already on the machine or is being installed.


Non-versioned Files Are User Data — All other things being equal, if the Modified date is later than the Create date for the file on the machine, do not install the file because user customizations would be wiped out. If the Modified and Create dates are the same, install the file. If the Create date is later than the Modified date, the file is considered unmodified, install the file.


Non-versioned Files Using Companion — All other things being equal, a non-versioned file that is associated with a versioned file using the companion mechanism abides by the rules for the versioned file. The only exception is if the versioned file on the machine and the versioned file being installed have the same version and language but the companion file is missing on the machine. In this case the companion file being installed is used even though the versioned file on the machine is used.


Rules Are Global — The rules for determining when to install a file reside in one place within the installer and are global, meaning they apply to all files equally.

What are MergeModules

Merge modules provide a standard method by which developers deliver shared Microsoft® Windows® Installer components and setup logic to their applications. Merge modules are used to deliver shared code, files, resources, Registry entries, and setup logic to applications as a single compound file. Developers authoring new merge modules, or using existing merge modules, should follow the standard outlined in this section.


A merge module is similar in structure to a simplified Windows Installer .msi file. However, a merge module cannot be installed alone, it must be merged into an installation package using a merge tool. Developers wanting to use merge modules must obtain one of the freely distributed merge tools, such as Mergemod.dll, or purchase a merge tool from an independent software vendor. Developers can create new merge modules by using many of the same software tools used to create a Windows Installer installation package, such as the database table editor Orca provided with the Windows Installer SDK.


When a merge module is merged into the .msi file of an application, all the information and resources required to install the components delivered by the merge module are incorporated into the application's .msi file. The merge module is then no longer required to install these components and the merge module does not need to be accessible to a user. Because all the information needed to install the components is delivered as a single file, the use of merge modules can eliminate many instances of version conflicts, missing Registry entries, and improperly installed files.

ActiveSetup Implementation

If you are using Windows Installer for per-machine-based installations, it could be the case that your setup contains components with user-related resources that have no entry-points to initiate the install-on-demand/self healing function of MSI. This, of course, will mean that when deployed the package will not install the user resources required to run the application properly.


But wait, don’t lose hope! In such a case you can use the Active Setup for a self healing on demand. It needs just one registry key in your msi file.







This registry key can be assigned to any Component that installs per-machine resources or you can create one component just for this key.


How it works:
The value in the StubPath key will be executed at a special time during which the Active Setup tasks are running and no other Windows Installer processes are running in the background that could cause the repair not to run (which would be the case if you attempted to run this command in the Run-Once registry key).
The command will thereby perform a repair for HKCU registry keys and missing files.


If this command runs successfully, it will create a registry key in HKCU and the command will not run again. However, if you wish to trigger this command again, because of a small update, then use the Version Key and increment its value each time you wish to run this command again when a user logs in.


Important Note:
Remember to use this command only if your setup does not contain any entry-point that would not allow the repair on demand, because this repair will run when a user on the target workstation logs in after the installation has been run. That means, even if the user doesn’t use the installed application, it will run the repair. And as you may already know, those repairs can take some time depending on the workstation’s hardware configuration and the size of the package.

SetACL Permissions Examples

Using SetACL to provide permissions

Command1: Providing registry permissions to Authenticated Users group


1.  setacl.exe "MACHINE\SOFTWARE\AHouse\GEPUIS ORBIX" /registry /grant "Authenticated Users" /full /i:cont_obj_inh /p:yes /r:cont_obj /silent


OR using S-ID


"MACHINE\SOFTWARE\AHouse\GEPUIS ORBIX" /registry /set "S-1-5-11" /full /sid /silent



Command2: Providing Folder permissions to Authenticated Users group


setacl.exe "c:\AudioTools\GIMP" /dir /set "S-1-5-11" /change /sid /silent



Change the group name / S-ID according to your requirement

Difference Between Execute Immediate and Execute Deferred

• Deferred custom actions can only be sequenced between the InstallInitialize and InstallFinalize actions in execute sequence tables. Immediate custom actions, on the other hand, can be sequenced anywhere within any of the sequence tables.

• Deferred custom actions cannot access the installation database. In fact, deferred custom actions have very limited access to the installation session because an installation script can be executed outside of the installation session that created it. Immediate custom actions have access to the installation database and can read and set installation properties, modify feature and component states, and add temporary columns, rows, and tables among other things.

• While both deferred and immediate custom actions can run in the context of the user initiating the installation, only deferred custom actions can run elevated using the system context.

• Deferred custom actions are not executed immediately. Instead they are scheduled to run later during the execution script. The execution script isn't processed until the InstallExecute, InstallExecuteAgain, or InstallFinalize action is run.

What is Application Packaging

Application Packaging is all about customizing applications according to best practices and User requirements.

Application packaging can help enterprises manage growing volumes of software for desktop and server systems efficiently. By streamlining software
configuration and deployment, application packaging can help reduce application management costs.

AdminStudio Installshield Online Training Training

New batch of Application Packaging Classroom training using Installshield/Wise Packaging Studio is starting at Hyderabad on3rd September. If you are interested contact me at 91-9963678795 or Virtual.App.Packager@gmail.com


For training details please visit www.AppRepack.in