Forcefully removing the 'Installation Directory' during uninstallation..

Most frequent defect that is logged against an Application Package is around "the installation directory not deleted during uninstallation" and we all know that based on Windows Installer design, the files / folders that are not created by the installer will not be removed by the installer. But the user would always want a clean system after uninstallatoin :)

So here you go with the approach to remove the installation directory via Direct Editor.

In the following example, I have a Basic MSI Project created using InstallShied 2012 Spring edition and assume that your application would create some files in the installed directory after installation, which would invalidate the removal of installation directory during uninstallation. The same solution applies to InstallScript MSI Project as well.

Take a look at the RemoveFiles table. You can remove specific files and files using wildcards. Once you remove those files, the folder should get removed as well on uninstall.
Something like the following should do the trick:
_MyFilesToRemove, <SomeComponentKey>, *.*, INSTALLDIR, 2

where <SomeComponentKey> is a key to an entry in the Component table. Any component will do, but if there is an .exe that actually creates the binary files, then perhpas you would want to use that .exe's component as you would only want the files to get removed when the corresponding .exe is removed.
Also, you may want to change *.* to *.<SomeSpecificExtension>

[Note: The above solution is basically an excerpt from MartinMarkevics's post in a community website.]

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.

Want to avoid 32bit installation on 64bit machine when you maintain a single project for both 32bit and 64bit?

If you are looking to maintain single project for 32bit and 64bit installers and want to avoid 32bit installation on the 64bit machine. You can do it using the following steps.

Step1: InstallScript function needs to be created. As follows

 // Function Delaration
export prototype MyFunction(HWND);
 // Function Definition
function MyFunction(hMSI)
// To Do: Declare local variables.

NUMBER nvSize;

begin

nvSize = 255;     

MsiGetProperty (hMSI, "VersionNT64", svVersionNT64, nvSize);

//MessageBox(svVersionNT64, WARNING);

if ( svVersionNT64 != "" ) then

                MessageBox(@IDSD_WARNING_64BIT, WARNING);

endif;

end

 

Step2: Define this in you String Table.

IDSD_WARNING_64BIT, WARNING = The 64-bit version of Windows has been detected. Installation of this [Product] on this platform cannot proceed, and will be cancelled. Please install this version of SecureDoc only on a 32-bit version of Windows platform.

Step 3: Create an InstallScript Custom action.

Call the above created function in this custom acation.

This custom action this should called after AppSearch in the Install Exec Sequence with the following condition ISReleaseFlags><"MyReleaseFlag" .

Note: This code sample applies to Basic MSI Projects and verified with InstallShield 2010, 2011. 2012 SP1 and 2012 Spring Edition.