Planning for a New Installer? Be ready with these Parameters..

Installer is NOT a last minute Surprise!

When you start with an all new Product or creating an ancillary kit or application for the existing product line, we may have to create a new installer for the deployment. With the Agile Methodology for development, at the end of each iteration, the product should be in a shippable state. Hence designing and developing the installer in parallel along with the product development would help us not only to have the product ready in a shippable state at the end of the iteration but also helps the QA to verify quickly.

·         Application Name

·         Application Description

·         Application Version Number

·         Company Name

·         Support Information to be displayed in ARP Panel

     a.   Publisher Name, URL

     b.   Contact Name, URL

     c.   Support Phone Number

     d.   Read Me File, if any

     e.   Product Update URL

      f.   Comments, if any

·         License Agreement, if any

·         Hardware Requirements

·         Default Installation directory

·         Installation condition like

       a.    Supported Operating System

       b.    Supported Platform - 32-bit / 64-bit

       c.    Admin privilege required?

·         Add / Remove programs entry required?

·         Icon & Images

                    a.    Product specific icon for ARP entry and installer output file?
                    b.  Custom Images for Installer dialog and installer startup splash screen 

        c.   Billboard (images run in background during installation) required?

·         List the Pre-Requisite software checks  (example .Net Framework 4.0 etc.,)
·         Do you need to ship any Pre-Requisite software along with the installer? If yes, list them

·         Silent installation required?

·         Globalization / Localization support? If yes, list the supported languages

·         Shortcuts? If yes, provide the name and physical path (relative to the installation directory) for all the proposed shortcuts

·         Do you bundle any merge module?

·         Answer these questions for succeeding release of the product

a.    Detect previous version?

b.    Do we need to support co-existence with the previous versions of should we upgrade?

c.    Upgrade should me a Patch or Minor upgrade or Major Upgrade.

[Note: It’s a good practice to plan the release artifacts in advance.]

·         Feature Details

o   Feature List with name and description

o   Feature / Component / File association

o   Optional or Mandatory feature

·         UI sequence for installation

o   Custom dialog, if any for user input

·         Post installation configuration like..

o   Create a Service

o   Create a Website / Virtual directory / App Pool

o   Restart IIS

o   Update config files

o   Register a  DLL

o   Create a database / Run a query / attacha a database

·         UI sequence for maintenance mode (remove, repair or modify)

o   Custom dialog, if any for user input  - modify option

·         Pre or Post uninstallation configuration like..

o   Delete a Service

o   Delete Website / Virtual directory / App Pool

o   Restart IIS

o   Update config files

o   unregister the  DLL

o   Remove the database / detach a database

·         Mode of deployment

o   Large scale deployment through SMS or Active Directory or Citrix Server

o   Web Deployment

o   Click Once Deployment

o   Stand Alone Server / Client

With these inputs, Agile Team can define the scope of the installer and estimate all the associated tasks for Installer development as well as testing.

·         Reboot required at the end of installation / uninstallation       

·         Windows Logo Guide lines Validation for the installer - Mandatory / Optional?

How to create a Pre-Requisite in InstallShield?

We have plenty of Pre-Requisites available in <Program Files>\InstallShield\2012\SetupPrerequisites folder and some times you may need to bundle / distrubute a thrid party msi or setup.exe along with your installer as a pre-requiste.

Here’s the way to create pre-requisites (.prq) in InstallShield for an exe or msi. 

1.)    Launch InstallShield IDE, Open Tools->Pre-requisite editor (or) Programs Shortcut -> InstallShield -> InstallShield 2012 Tools -> InstallShield Prerequisite Editor

2.)    A unique GUID is generated for each launch of the Prerequisite Editor.  Use the default one or otherwise, have a new one in the field specified under the “Properties”  tab.

3.)    Specify any condition, like registry entry or file exists, in the “Conditions” tab.

4.)    Select the files to be included under the “Files to Include”  tab. This is the exe or msi.

5.)    Under “Applications to run” tab select the file that must be launched to install the prerequisite.  This must include only the files specified in “Files to Include”.

6.)    Choose “Behavior” and “Dependency”  as needed.

For more information on this see here.

Note: The installer output should be a Setup.exe to include a Pre-Requiste (.prq).

Build Process Overview

The build process is an art (ofcoruse an engineering process) of getting a shippable / deployable artifacts for any software product. The steps to create the installable component / artifact from the code base would remain the same irrespective of the Product Technology, Packaging Software, Build automation Tools and Source Control Software (TFS, Subversion, Seapine Surround etc.) used.

The build process is categorized into five main stages as described below

Key Point: Intimate the stake holders through an automated email on success or failure of the build, at any stage.

1.       Preparing the Build Environment

a.   Clean the Build Working directory (BuildScripts, Product / Installer source code, previous artifacts etc.

b.   Checkout the version header files (usually assembly info files), update it with the latest build number and check-in back to Source Control. This can be done with some 3rd party tool or even with a small in house tool

c.   Label the branch or create a snapshot branch

d.   Get the Product / Installer source from source control system based on the label or snapshot branch created in the previous step.

2.       Actual Build Process

a.   Compile the Product source

b.   For more than one installer, which requires independent Staging area, repeat the step 2b.

                             i.    Form the Staging area

                             ii.   Compile the installers / merge modules

                  [Note: Staging Area is the deployment structure with recently compiled assemblies and misc files in an organized folder structure.]

3.       Post Build Process

a.   Consolidate the logs to a common location

b.   Copy the reference merge modules / assemblies to the Artifacts folder and check-in

                             i.     Checkout the files / folder

                             ii.    Copy the reference merge modules / assemblies to the Artifacts folder

                             iii.   Check-in them back.

c.   Copy the Installers to Artifacts folder

d.   Compress the Artifacts, if required (7z works well for command line compression)

e.   Copy the Artifacts, Source Code etc to common release area for permanent archival and ftp the same if required.

4.      Deploying on Sandbox machine

             a.  Rever to the existing snapshot of the Sandbox machine

             b.  Copy the installer to the Sandbox machine

             c.  Install & Configure

5.      Running Automated Test Suite

             a.  Invoke the Automated Test Suite. On need basis, one or more Virtualized Images can be 

                  used for running / verifying the automation suite.

Connect to TFS with different Credentials

Very recently I stumbled upon a problem that launching Vistual Studio 2010 / Team Explorer 2010 to access Team Foundation Server 2010 always took me to the default login which had limited privilege (only few projects were accessible).

runas /netonly /user:domain\username <Program Files>\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe"

/netonly : Indicates that the user information specified is for remote access only. It just tells runas that the credentials will be used for accessing remote resources

Thanks to stackoverflow for the solution.. here you go with the reference post.

SCM Commands - A Comparison

During Build Automation, accessing the source control via command line and performing various operations like getting the source, check-out & check-in of the updated version information files, creating a snapshot branch / labeling etc., plays a cruicial role.

Here is a list of most widely used SCM commands from TFS, Surround SCM and Subversion.
 

SCM Commands - A Comparison



The above table is based on my understanding and any suggestions / comments are welcome.

Updating an xml file using VBScript Custom Action

1. Create a VBScript Custom Action stored in Binary Table (MSI Type Number: 6)
2. Here is the Sample xml file (say address.xml), which is considered for updating in the below VBScript CA
        <Address>
             <Name>Smitha</Name>
             <Address1>123B, 16th Cross</Address1>
             <City>Bangalore</City>
        </Address>
3. Write the following code in the VBScript file

Function UpdateXMLFile
     On Error Resume Next               
         
    Set objDOM  = CreateObject("Microsoft.XMLDOM")
    Set objParentNode = CreateObject("Microsoft.XMLDOM")    
    if Err.Number = 0 then                       

                       ' Declaration
                       dim FileName
                       dim name
                       dim address1
                       dim city

   Set objNet = CreateObject("WScript.NetWork")                
   set objNet=nothing                
              
    name=Session.Property("NAME")    
    address1=Session.Property("ADDRESS1")
    city=Session.Property("CITY")
 
     'update address.xml file
      FileName= Session.Property("INSTALLDIR")+"\"+"address.xml" 
      objDOM.async = false  
      objDOM.load(FileName)                                                
     if (trim(name)<>"" and trim(address1)<>"" and trim(city)<>"") then
         ' update name
          strXPath = "/Address/@Name"
          set objParentNode = objDOM.selectSingleNode(strXPath)
          objParentNode.text = name           
 
         ' update address1
          strXPath = "/Address/@Address1"
          set objParentNode = objDOM.selectSingleNode(strXPath)
          objParentNode.text = address1           
 
        ' update name
         strXPath = "/Address/@City"
         set objParentNode = objDOM.selectSingleNode(strXPath)
         objParentNode.text = city 
  
         objDOM.Save(FileName)

                     end if
                 end if
           end function ' End of UpdateXMLFile
  4.    Set the following properties for the Custom Action (RestartIIS)

  Script Function -> UpdateXMLFile
  Return Processing -> Synchronous (Check exit code)
  In-Script Execution -> Immediate Execution
  Install Exec Sequence -> After InstallFinalize
  Install Exec Condition -> &FeatureA=3 and Installed.

This condition means that FeatureA is selected for installation and the FeatureA is installed (Installed state will be true as the CA is scheduled to execute after InstallFinalize).       

  [Note: This code snippet is tested with InstallShield 2012 Basic MSI Project. Should be compatible with earlier versions of InstallShield as well.]

Restarting IIS in MSI using VBScript Custom Action

This article focus on writing a Simple VBScript Custom Action to Restart IIS.

1. Create a VBScript Custom Action (RestartIIS) Stored in Binary Table (MSI Type Number: 6)

2. Write the following code in the VBScript file

Function RestartIIS()
     Set wsShell = CreateObject("WScript.Shell")
     Set fso = CreateObject("Scripting.FileSystemObject")
     winPath = WsShell.ExpandEnvironmentStrings( "%windir%" )
     netPath = fso.BuildPath( winPath, "system32" )
     toolPath = fso.BuildPath( netPath, "iisreset.exe" )
     WsShell.Run toolPath, 0, true
     set fso=nothing
     set WsShell=nothing  
End Function

3. Set the following properties for the Custom Action (RestartIIS) 

    Script Function -> RestartIIS
    Return Processing -> Synchronous (Check exit code)
    In-Script Execution -> Immediate Execution
    Install Exec Sequence -> After InstallFinalize
    Install Exec Condition -> &FeatureA=3 and Installed
                                           This condition means that FeatureA is selected for installation and the FeatureA is installed (Installed state will be true as the CA is scheduled to execute after InstallFinalize).

[Note: This code snippet is tested with InstallShield 2012 Basic MSI Project. Should be compatible with earlier versions of InstallShield as well.]

How to set Focus on your Installer dialog?

When we run an installer, sometimes the control switches between your installer and other application's screen, which might shift the focus from the installer dialog.

Here is how you can make sure to stay on top of your installer dialog unless you swtich explictly.

Call the function - SetInstallerDlgFocus(), before invoking each dialog, so that your installer will be always available in the foreground.

// Included header files
#include "WinApi.h"  // Required to Make Win32 API Calls

// Function declaration
prototype SetInstallerDlgFocus();

// Function definition
///////////////////////////////////////////////////////////////////////////////
//  FUNCTION:   SetInstallerDlgFocus
//  Purpose:    Bring window to the foreground. 
///////////////////////////////////////////////////////////////////////////////
function SetInstallerDlgFocus()
    HWND hDialog;
begin
      hDialog = GetWindowHandle(HWND_INSTALL);
      SetForegroundWindow(hDialog);
end; // end of SetInstallerDlgFocus

[Note: This applies to InstallScript MSI and Pure InstallScript type projects.]