Installation is Rolled-back while creating the VirtualDirectory?

We have a Basic MSI Project created in InstallShield 2012 SP1, which packages a Simple .Net web application. First release of the product was gone, the Installation and uninstallation is working fine.
While making some incremental changes to the installer during second release the installer fails to create the Virtual Directory and started rolling back the installation.

Further exploration revealed that the Installation rollback happens while creating a mapping between the IIS Application and Physical path. There can be two reasons that the installation gets rolled-back while creating a mapping between IIS Application and Physical path.

1. If the web.config is in read only the installation will roll back as it can’t edit the file. But I am not attempting to explictly edit the web.config file while creating the virtual directory.
2. If you are trying to map the website to an empty folder then also it will rollback. A valid point:).. why do you want to create a website without any file?

So please make sure that the web.config file's read-only attribute is removed before bundling the file with the installer.

Note: The contents in this article is verified in InstallShield 2012 SP1 Premier Editions with Basic MSI Project.

Using Single InstallShield Project for building both 32bit and 64bit Installers..

Earlier days, we started with 32bit installers and continued to install 32bit application on 64bit machine. Later pure 64bit applications became inevitable. So in addition to the existing 32bit installer, we started creating separate Installshield Project for 64bit installers. Hence we have been creating two different InstallShield Project (ism file) for delivering 32bit and 64bit installers. But as the installer feature grows and considering the maintenance overhead spanned across subsequent releases throughout the product's life time, it would be good if we can have a common InstallShield Project file to support 32bit and 64bit installers. This article would be a discourse with a case study rather than the steps involed in creating such an InstallShield Project.

Case Study:

Project Specification:

• Common InstallShield Project for both 32bit & 64bit installer.
• Installation directory to be set based on a Pre-Req Software (say MS Office - Outlook's ADDINS folder).
• Three Features, having couple of files to be delployed based on Component Best Practice. One DLL is common for both 32b & 64b, a DLL specific to 32b and a DLL specific to 64b.
• Registry entries to be created to store the installation directory and version information.

Steps to create the Installer:
1. Create a New Basic MSI Project and update basic informations like Product Name, Product Version etc., and Leave the Template Summary under General Information -> Summary Information unaltered.
2. Create Features / Components
 

Features	Components	Release Flag	64-Bit Component
Feature 1
	32b_RegistryComponent	32bFlag
	64b_RegistryComponent	64bFlag
	MyCommonDLL		No
Feature 2
	32b_DLL2.dll	32bFlag	No
Feature 3
	64b_DLL2.dll	64bFlag	Yes

3. Defining System Search for framing the installation directory
 Create Two System Search as follows
    Read Path from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Outlook\InstallRoot and set its value to OUTLOOK_32B
    Read Path from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Outlook\InstallRoot and set its value to OUTLOOK_64B (Select Read the Value from 64bit Registry)
4. Redirecting the installation directory
Any product that needs to be installed usually have its own installation directory or will get deployed into any of the existing product suite's installation directory. Our current example has a set of DLLs that has to be installed onto ADDINS folder under MS Office - Outlook's installation directory. Here is how you can set the installation directory dymanically..
Create two Set Directory  Custom Actions (say Set64bInstallDir and Set32bInstallDir as follows
 

Custom Action Property	Set64bInstallDir	Set32bInstallDir
Directory	INSTALLDIR	INSTALLDIR
Directory Value	[OUTLOOK_64B]\ADDINS	[OUTLOOK_32B]\ADDINS
Install UI Sequence	After CostFinalize	After Set64bInstallDir
Install UI Condition	ISReleaseFlags=”64bFlag” AND NOT Installed	ISReleaseFlags=”32bFlag” AND NOT Installed
Install Exec Sequence	After SetAllUsers	After Set64bInstallDir
Install Exec Condition	ISReleaseFlags=”64bFlag” AND NOT Installed	ISReleaseFlags=”32bFlag” AND NOT Installed

[Note: Alternatively you can also use Set Property custom action to redirect the installation directory.] 

5. Creating 32b / 64b specific Registry Keys

For both 32b_RegistryComponent  & 64b_RegistryComponent  components, create the following keys under HKLM to store the application’s installation directory and version informationHKLM\Software\MyCompany\MyProduct
        InstallDir – [INSTALLDIR]
        Version   -  [ProductVersion]
During installation the property values [INSTALLDIR], [ProductVersion] will be resolved into the original values.The only difference here is to Set 64-Bit Component to YES for 64b component.

6. Release Configurations / flags
     Create two release configurations (say 32bReleaseConfig & 64bReleaseConfig) using Release Wizard. Set the values as follows for both the releases.

	64 bit	32 bit
Product Configuration Flags	64bFlag	32bFlag
Template Summary	x64,1033	x86,1033

Now you have are ready with the common InstallShield project, which will created two different installers for 32-Bit and 64-Bit. Here you go with some tips if you Want to avoid 32bit installation on 64bit machine when you maintain a single project for both 32bit and 64bit? 

Note: This article applies to Basic MSI Project using InstallShield 2012 Premier Edition but should work in upcoming versions of InstallShield as well.