To launch PDF as ReadMe file on the Installation Success using InstallShield

This will guide you to how to open a PDF at the end of the installation if the read me check box is selected by the user. To achieve these are the steps needs to be followed

1.      Registry search for adobe reader location

2.      Create a custom action to launch readme file

3.      Modify the SetupCompleteSucess Dialog

4.      Add some properties to Property Manager

Registry search for adobe reader location

·         Open InstallShield and go to Behavior and Logics & System search

·         Now right click and add a new system search

·         Click and choose for registry entry and enter the following values

o   Registry root: HKEY_LOCAL_MACHINE

o   Registry path: SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\AcroRd32.exe

o   Registry value: path

·         Click next and Store the value in this property, in that field enter ADOBEPATH. Just leave the option "Store the value in the property".

Custom Action

·         Go to custom actions and create "New EXE" -> "Path referencing a directory" and name it as LaunchReadMePDF.

·         Set the "Working Directory" to documents folder path(In my case it is INSTALLDIR).

·         Set the "Filename & Command line" to "[ADOBEPATH]AcroRd32.exe" "[INSTALLDIR]ReadMe.pdf"

·         Set "Return Processing" to "Asynchronous (No wait for completion)"

SetupCompleteSuccess Dialog

·         Go to Dialogs & SetupCompleteSuccess Behavior

·         In the Controls go to OK and add an event and  enter the following
Event = DoAction
Argument = LaunchReadMePDF
Condition = LAUNCHREADME

Property Manager

Go to Property Manager and add the following Properties

·       ·           SHOWLAUNCHREADME and set it to -1

·       ·           READMEFILETOLAUNCHATEND and set to 1

For this process to work Readme.pdf file should be deployed to INSTALLDIR as part of file copy or you can change the path accordingly.

Combining Uninstall / Change on same button in ARP Panell

Have you ever noticed that double-clicking any program / entry in Add / Remove Programs panel triggers Uninstallation and the application will be removed completely? The user does not have choice to select the options from the maintenance mode window. I have observed this behaviour with Installers created in Wise as well as InstallShield.
This article focus on the limitation associated with this behaviour in InstallShield Basic MSI project and provides a workaround for the same.

Further exploration unveiled that for some applications, the default action (bolded item) is "Uninstall/Change", where as a Basic MSI project created in InstallShield has 3 options as "Uninstall", "Change" and "Repair" and the default (in Bold) action is "Uninstall". My current case is to have "Uninstall/Change" option for our software instead of 3 Options.

For this InstallShield provided a solution with a disclaimer that this has not been tested at their end! But the solution worked like a charm for our application and hence would like to share it ..

By default, Windows Installer allows the creation of the “Repair”, “Change” and “Uninstall” buttons in order to maintain your application. The downside of this method is that the “Repair” and “Uninstall” actions are done in a basic user interface. There is no direct method available in InstallShield to achieve this. But tweaking some registry entries, you can make changes in display of ARP. You can make appropriate backup of registry and then try it.

For displaying Uninstall\Change on same button in ARP, disable all display options under General information->Add/Remove programs.

In the registry options, create the following registry key under the Current User/ Local Machine hive:

Software\Microsoft\Windows\CurrentVersion\Uninstall\MyApplication

where MyApplication is the Product Name you assigned for them.

In MyApplication registry key, create the following registry entries..

Name	Type	Data
DisplayIcon	REG_SZ	[SystemFolder]msiexec.exe
DisplayName	REG_SZ	[ProductName]
HelpLink	REG_SZ	[ARPHELPLINK]
InstallLocation	REG_SZ	[APPDIR]
Publisher	REG_SZ	[Manufacturer]
UninstallPath	REG_SZ	[SystemFolder]msiexec.exe /i [ProductCode]
UninstallString	REG_SZ	[SystemFolder]msiexec.exe /i [ProductCode]
URLUpdateInfo	REG_SZ	[ARPURLINFOABOUT]
DisplayVersion	REG_SZ	[ProductVersion]
Language	REG_DWORD	[ProductLanguage]
URLUpdateInfo	REG_SZ	[ARPURLUPDATEINFO]
URLInfoAbout	REG_SZ	[ARPURLINFOABOUT]
Comments	REG_SZ	[ARPCOMMENTS]

 

Then add the ARPSYSTEMCOMPONENT to Property Manager and set the value as 1.

After successful installation, you can view the "Uninstall/Change" button on your application from Add / Remove Programs Panel.

[Note: This information has been verified with a Basic MSI project created in InstallShield 2012 Spring Edition.]

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.