Test String for alphanumeric characters

Hello Friends, i had used a very useful installscript function for testing a string for alphanumeric characters. The function will accept the string to be tested as a parameter.
You can use the below code and can edit according to your need.

prototype IsAlphanumeric (string);

function IsAlphanumeric (szStuff)
     /* Check if a string is alphanumeric
         In: szStuff -- string to test
         Out: Returns TRUE or FALSE
     */
      #define ALPHANUMERIC_CHARS "abcdefghijklmnopqrstuvwxyz_0123456789"
     // For my purposes, underscore is considered alphanumeric.
     number nPos;
     string szChar;
begin
     for nPos = 0 to StrLength (szStuff)
          StrSub (szChar, szStuff, nPos - 1, 1);
          if !(ALPHANUMERIC_CHARS % szChar) then
              return FALSE;
         endif;
    endfor;
    return TRUE;
end;

Creating custom file browse dialog

Hi, here I have to share you an interesting post for including a file browse dialog into our Installscript project. 

Here we use a Windows API GetOpenFileNameA for the purpose. 

We will use two files named brwsdlg.h and Brwsdlg.rul. Follow these simple steps as explained below:

1. Open the Installation Designer view.
2. Under Behavior and Logic, select InstallScript.
3. Right-click on your setup.rul file and select New Script File.
   
4. Name it as brwsdlg.h. Similarly create brwsdlg.rul file.
5. Paste the below code in brwsdlg.h script .
   
   // Avoid multiple include collisions.
   #ifndef _BRWSDLG_H_
   #define _BRWSDLG_H_
   
   
   // Options for Flags member of OPENFILENAME.
   #define OFN_READONLY 0x00000001
   #define OFN_OVERWRITEPROMPT 0x00000002
   #define OFN_HIDEREADONLY 0x00000004
   #define OFN_NOCHANGEDIR 0x00000008
   #define OFN_SHOWHELP 0x00000010
   #define OFN_ENABLEHOOK 0x00000020
   #define OFN_ENABLETEMPLATE 0x00000040
   #define OFN_ENABLETEMPLATEHANDLE 0x00000080
   #define OFN_NOVALIDATE 0x00000100
   #define OFN_ALLOWMULTISELECT 0x00000200
   #define OFN_EXTENSIONDIFFERENT 0x00000400
   #define OFN_PATHMUSTEXIST 0x00000800
   #define OFN_FILEMUSTEXIST 0x00001000
   #define OFN_CREATEPROMPT 0x00002000
   #define OFN_SHAREAWARE 0x00004000
   #define OFN_NOREADONLYRETURN 0x00008000
   #define OFN_NOTESTFILECREATE 0x00010000
   #define OFN_NONETWORKBUTTON 0x00020000
   #define OFN_NOLONGNAMES 0x00040000
   #define OFN_EXPLORER 0x00080000
   #define OFN_NODEREFERENCELINKS 0x00100000
   #define OFN_LONGNAMES 0x00200000
   
   
   // CommDlgExtendedError-related defines.
   #define CDERR_DIALOGFAILURE 0xFFFF
   #define CDERR_DIALOGFAILURE_MSG "The file browse dialog box could not be created."
   // The dialog box could not be created. The common dialog box function
   // call to the DialogBox function failed. For example, this error occurs
   // if the common dialog box call specifies an invalid window handle."
   #define CDERR_FINDRESFAILURE 0x0006
   #define CDERR_FINDRESFAILURE_MSG "The file browse dialog box function failed to find a specified resource."
   // The common dialog box function failed to find a specified resource.
   #define CDERR_INITIALIZATION 0x0002
   #define CDERR_INITIALIZATION_MSG "The file browse dialog box function failed during initialization."
   // The common dialog box function failed during initialization. This error
   // often occurs when sufficient memory is not available.
   #define CDERR_LOADRESFAILURE 0x0007
   #define CDERR_LOADRESFAILURE_MSG "The file browse dialog box function failed to load a specified resource."
   // The common dialog box function failed to load a specified resource.
   #define CDERR_LOADSTRFAILURE 0x0005
   #define CDERR_LOADSTRFAILURE_MSG "The file browse dialog box function failed to load a specified string."
   // The common dialog box function failed to load a specified string.
   #define CDERR_LOCKRESFAILURE 0x0008
   #define CDERR_LOCKRESFAILURE_MSG "The file browse dialog box function failed to lock a specified resource."
   // The common dialog box function failed to lock a specified resource.
   #define CDERR_MEMALLOCFAILURE 0x0009
   #define CDERR_MEMALLOCFAILURE_MSG "The common dialog box function was unable to allocate memory for internal structures."
   // The common dialog box function was unable to allocate memory
   // for internal structures.
   #define CDERR_MEMLOCKFAILURE 0x000A
   #define CDERR_MEMLOCKFAILURE_MSG "The common dialog box function was unable to lock the memory associated with a handle."
   // The common dialog box function was unable to lock the memory associated
   // with a handle.
   #define CDERR_NOHINSTANCE 0x0004
   #define CDERR_NOHINSTANCE_MSG "The ENABLETEMPLATE flag was set, but you failed to provide a corresponding instance handle."
   // The ENABLETEMPLATE flag was set in the Flags member of the initialization
   // structure for the corresponding common dialog box, but you failed to provide
   // a corresponding instance handle.
   #define CDERR_NOHOOK 0x000B
   #define CDERR_NOHOOK_MSG "The ENABLEHOOK flag was set, but you failed to provide a pointer to a corresponding hook procedure."
   // The ENABLEHOOK flag was set in the Flags member of the initialization
   // structure for the corresponding common dialog box, but you failed to provide
   // a pointer to a corresponding hook procedure.
   #define CDERR_NOTEMPLATE 0x0003
   #define CDERR_NOTEMPLATE_MSG "The ENABLETEMPLATE flag was set, but you failed to provide a corresponding template."
   // The ENABLETEMPLATE flag was set in the Flags member of the initialization
   // structure for the corresponding common dialog box, but you failed to provide
   // a corresponding template.
   #define CDERR_REGISTERMSGFAIL 0x000C
   #define CDERR_REGISTERMSGFAIL_MSG "The RegisterWindowMessage function returned an error code when it was called by the file browse dialog box function. "
   // The RegisterWindowMessage function returned an error code when it was called
   // by the common dialog box function.
   #define CDERR_STRUCTSIZE 0x0001
   #define CDERR_STRUCTSIZE_MSG "The lStructSize member of the initialization structure for the corresponding file browse dialog box is invalid. "
   // The lStructSize member of the initialization structure for the corresponding
   // common dialog box is invalid.
   #define FNERR_BUFFERTOOSMALL 0x3003
   #define FNERR_BUFFERTOOSMALL_MSG "The buffer pointed to by the lpstrFile member of the OPENFILENAME structure is too small for the filename specified by the user."
   // The buffer pointed to by the lpstrFile member of the OPENFILENAME structure
   // is too small for the filename specified by the user. The first two bytes
   // of the lpstrFile buffer contain an integer value specifying the size, in bytes
   // (ANSI version) or 16-bit characters (Unicode version), required to receive the full name.
   #define FNERR_INVALIDFILENAME 0x3002
   #define FNERR_INVALIDFILENAME_MSG "A filename is invalid."
   // A filename is invalid.
   #define FNERR_SUBCLASSFAILURE 0x3001
   #define FNERR_SUBCLASSFAILURE_MSG "An attempt to subclass a list box failed because sufficient memory was not available."
   // An attempt to subclass a list box failed because sufficient memory was not available.
   
   
   
   
   // OPENFILENAME structure. Notice that all string members below are declared
   // as LONG. For example, lpstrFilter. Do not use STRING.
   typedef OPENFILENAME
   begin
   LONG lStructSize;
   HWND hwndOwner;
   HWND hInstance;
   POINTER lpstrFilter;
   POINTER lpstrCustomFilter;
   LONG nMaxCustFilter;
   LONG nFilterIndex;
   POINTER lpstrFile;
   LONG nMaxFile;
   POINTER lpstrFileTitle;
   LONG nMaxFileTitle;
   POINTER lpstrInitialDir;
   POINTER lpstrTitle;
   LONG Flags;
   SHORT nFileOffset;
   SHORT nFileExtension;
   POINTER lpstrDefExt;
   POINTER lCustData;
   POINTER lpfnHook;
   POINTER lpTemplateName;
   end;
   
   
   // Windows API declares.
   prototype comdlg32.GetOpenFileNameA( LONG );
   prototype comdlg32.CommDlgExtendedError();
   prototype user32.wsprintf(STRING, STRING, POINTER);
   // Our file browse API, defined in matching .rul file.
   prototype FileBrowseDlg( BYREF STRING, NUMBER, STRING, STRING, STRING, BOOL, LIST , BOOL );
   
   
   #endif
   
   
6. Paste below code in Brwsdlg.rul file.
   
   #ifndef _BRWSDLG_RUL_
   #define _BRWSDLG_RUL_
   
   
   prototype Kernel32.RtlMoveMemory(BYREF STRING, POINTER, NUMBER);
   
   
   typedef STR260
   begin
   STRING sz[260];
   end;
   
   
   ///////////////////////////////////////////////////////////////////////////////
   // FileBrowseDlg() uses the Windows GetFileNameA function to allow single file
   // selection. Callers specify filter, dialog title, and initial browse directory.
   //
   // Input:
   //
   // szFile: String variable into which FileBrowseDlg() will place the selected
   // file's fully qualified pathname. The variable passed in as szFile must
   // be explicitly sized (declared as szMyFile[260] for example) and the
   // size must be passed in as the second parameter (nszFileSize).
   // szFile is passed by reference.
   //
   // nszFileSize: The size that szFile was explicitly declared as.
   //
   // szFilter: Filter spec for dialog. In the form "\0\0\0". For example:
   //
   // "Text files (*.txt)\0*.txt\0\0"
   //
   // The description ("Text files (*.txt)" above) must be separated from the
   // extension ("*.txt" above) by a "\0" character. The entire string must
   // end in a double null ("\0\0").
   //
   // szDialogTitle: A string containig the title to display on the file browse dialog.
   //
   // szInitialDir: A string specifying the directory the browse dialog opens to.
   //
   // bMultiSel: Set to TRUE if you wish to enable multiple selection.
   //
   // listFiles: List that will be loaded with directory and filenames if multiple
   // selection is enabled. List is passed by reference (by default,
   // since list variables are pointers).
   //
   // bDerefLinks: Set to TRUE to dereference link files to the file browse. 
   //
   // Return:
   //
   // Returns 0 when a file is successfully selected. Returns less than zero when
   // when the user cancels/closes the browse dialog or an error occurs. If an
   // error occurs, a message box displays the error identifier.
   //
   ///////////////////////////////////////////////////////////////////////////////
   
   function FileBrowseDlg( szFile, nszFileSize, szFilter, szDialogTitle, szInitialDir, bMultiSel, listFiles, bDerefLinks )
   OPENFILENAME ofn;
   STRING szMsg, szFileTitle[260];
   STRING szCustomFilter[260], szTemp[260];
   LONG nResult, n, nFlags, nErr; 
   STR260 str;
   begin
   
   UseDLL(WINSYSDIR ^ "comdlg32.dll");
   
   nFlags = OFN_FILEMUSTEXIST | OFN_PATHMUSTEXIST | OFN_HIDEREADONLY |
   OFN_NOCHANGEDIR | OFN_EXPLORER;
   if bMultiSel then
   nFlags = nFlags | OFN_ALLOWMULTISELECT;
   endif;
   if bDerefLinks = FALSE then
   nFlags = nFlags | OFN_NODEREFERENCELINKS;
   endif;
   
   nResult = GetWindowHandle(HWND_INSTALL);
   
   ofn.lStructSize = SizeOf(ofn);
   ofn.hwndOwner = nResult;
   // Notice how the address of an explicitly sized string
   // is used when assigning to a member who was declared
   // as a LONG string pointer (lpstr). For example, &szFilter.
   ofn.lpstrFilter = &szFilter;
   ofn.nFilterIndex = 1;
   
   //The string pointed to by lpstrFile is modified by
   //GetOpenFileName. The only way to have a string in
   //script to reflect the change is to point lpstrFile
   //to a structure that just a string member.
   str.sz = szFile;
   ofn.lpstrFile = &str;
   ofn.nMaxFile = SizeOf(str);
   
   ofn.lpstrFileTitle = &szFileTitle;
   ofn.nMaxFileTitle = 260;
   ofn.lpstrTitle = &szDialogTitle;
   ofn.Flags = nFlags;
   ofn.lpstrDefExt = &szTemp;
   ofn.lpstrInitialDir = &szInitialDir;
   ofn.hInstance = 0;
   ofn.lpstrCustomFilter = &szCustomFilter;
   ofn.nMaxCustFilter = 260;
   ofn.lpfnHook = 0;
   
   nResult = GetOpenFileNameA(&ofn);
   if nResult = 1 then 
   if bMultiSel then
   //A direct assignment in the form of szFile = str.sz
   //will result in all data beyond the first null to be
   //lost. This only happend when the string is assigned
   //with a structure member. This is the reason why a
   //very indirect method is being used the transfer the
   //contents of str.sz to szFile
   Resize(szFile, SizeOf(str));
   RtlMoveMemory(szFile, &str, SizeOf(str));
   StrGetTokens(listFiles, szFile, "");
   else
   szFile = str.sz;
   endif;
   else
   nErr = CommDlgExtendedError();
   switch (nErr)
   case CDERR_DIALOGFAILURE: szMsg = CDERR_DIALOGFAILURE_MSG;
   case CDERR_FINDRESFAILURE: szMsg = CDERR_FINDRESFAILURE_MSG;
   case CDERR_INITIALIZATION: szMsg = CDERR_INITIALIZATION_MSG;
   case CDERR_LOADRESFAILURE: szMsg = CDERR_LOADRESFAILURE_MSG;
   case CDERR_LOADSTRFAILURE: szMsg = CDERR_LOADSTRFAILURE_MSG;
   case CDERR_LOCKRESFAILURE: szMsg = CDERR_LOCKRESFAILURE_MSG;
   case CDERR_MEMALLOCFAILURE: szMsg = CDERR_MEMALLOCFAILURE_MSG;
   case CDERR_MEMLOCKFAILURE: szMsg = CDERR_MEMLOCKFAILURE_MSG;
   case CDERR_NOHINSTANCE: szMsg = CDERR_NOHINSTANCE_MSG;
   case CDERR_NOHOOK: szMsg = CDERR_NOHOOK_MSG;
   case CDERR_NOTEMPLATE: szMsg = CDERR_NOTEMPLATE_MSG;
   case CDERR_REGISTERMSGFAIL: szMsg = CDERR_REGISTERMSGFAIL_MSG;
   case CDERR_STRUCTSIZE: szMsg = CDERR_STRUCTSIZE_MSG;
   case FNERR_BUFFERTOOSMALL: szMsg = FNERR_BUFFERTOOSMALL_MSG;
   case FNERR_INVALIDFILENAME: szMsg = FNERR_INVALIDFILENAME_MSG;
   case FNERR_SUBCLASSFAILURE: szMsg = FNERR_SUBCLASSFAILURE_MSG;
   endswitch;
   if nErr != 0 then
   // User did not close or cancel dialog box.
   MessageBox("FileBrowseDlg() error:\n\n" + szMsg, SEVERE);
   endif;
   return -1;
   endif;
   
   UnUseDLL(WINSYSDIR ^ "comdlg32.dll");
   return 0; 
   end;
   #endif
   
   
7. Use below code in your setup.rul file. 
   
   Click on your setup.rul file to bring up your script in the right hand window and insert the following code to your script, after the #include "ifx.h" statement.
   
   #include "brwsdlg.h"
   #include "brwsdlg.rul"
   
   Add the following sample script to call the API to display the file browse dialog.
   function OnBegin()
   // FileBrowseDlg requires the szFile parameter be explicitly sized
   // and that the size be passed as the second parameter.
   STRING szFile[512], svDir, svFileList, svTemp;
   NUMBER nResult, nReturn;
   BOOL bMultiSel, bDerefLinks;
   LIST listFiles;
   
   begin
   // If I want to support multiple selection, set bMultiSel to TRUE
   // and pass in a valid string list.
   bMultiSel = TRUE;
   bDerefLinks = FALSE;
   listFiles = ListCreate(STRINGLIST);
   // Open the file browse dialog.
   nResult = FileBrowseDlg( szFile, 512, "All files (*.*)\0*.txt\0\0", "Select File", "c:\\", bMultiSel, listFiles, bDerefLinks );
   if nResult = 0 then
   if bMultiSel then
   // If I chose multiple selection, I must parse the info, which is stored
   // in list. First item will be dir, all others are individual filenames.
   nReturn = ListGetFirstString(listFiles, svTemp);
   while nReturn != END_OF_LIST
   svFileList = svFileList + svTemp + "\n";
   nReturn = ListGetNextString(listFiles, svTemp);
   endwhile;
   MessageBox("Directory (first item) and selected files:\n\n" + svFileList, 0);
   else
   // No multiple selection, so a single file/path was set.
   MessageBox("Selected file:\n\n" + szFile, 0);
   endif;
   endif;
   ListDestroy(listFiles);
   end;
   
   
   Note: You have to customize this code according to your needs.

Cache location of Windows installer

"C:\windows\Installer"

When we click "Remove" button from ADD/REMOVE panel, then the installer look for the source in this directory.

How can I use a custom action to dynamically populate rows in the table?

Immediate custom actions have full access to the Windows Installer database. All you need to do is use the database API to open a view and execute the view. The rest is the SQL query you create that performs an insert of a temporary row in the database. All of this, the APIs + SQL queries, are documented on MSDN in the Windows Installer documentation. If the table needs to be around in memory so that your changes aren't lost when dropped from view, then add a hold count to it (and release the hold count at the end after the requisite action runs).

* MsiGetActiveDatabase
* MsiDatabaseOpenView
* MsiViewExecute

MsiGetActiveDatabase

The MsiGetActiveDatabase function returns the active database for the installation. This function returns a read-only handle that should be closed using MsiCloseHandle.


MSIHANDLE MsiGetActiveDatabase(
MSIHANDLE hInstall
);

Parameters
hInstall
[in] Handle to the installation provided to a DLL custom action or obtained through MsiOpenPackage, MsiOpenPackageEx, or MsiOpenProduct.
Return Values
If the function succeeds, it returns a read-only handle to the database currently in use by the installer. If the function fails, the function returns zero, 0.

Remarks
The MsiGetActiveDatabase function accesses the database in use by the running the installation.

Note that it is recommended to use variables of type PMSIHANDLE because the installer closes PMSIHANDLE objects as they go out of scope, whereas you must close MSIHANDLE objects by calling MsiCloseHandle.

For example, if you use code like this:


MSIHANDLE hRec = MsiCreateRecord(3);

Change it to:


PMSIHANDLE hRec = MsiCreateRecord(3);

MsiDatabaseOpenView
The MsiDatabaseOpenView function prepares a database query and creates a view object. This function returns a handle that should be closed using MsiCloseHandle.


UINT MsiDatabaseOpenView(
MSIHANDLE hDatabase,
LPCTSTR szQuery,
MSIHANDLE* phView
);

Parameters
hDatabase
[in] Handle to the database to which you want to open a view object. You can get the handle as described in Obtaining a Database Handle.
szQuery
[in] Specifies a SQL query string for querying the database. For correct syntax, see SQL Syntax.
phView
[out] Pointer to a handle for the returned view.
Return Values
The MsiDatabaseOpenView function returns one of the following values:
ERROR_BAD_QUERY_SYNTAX
An invalid SQL query string was passed to the function.
ERROR_INVALID_HANDLE
An invalid or inactive handle was supplied.
ERROR_SUCCESS
The function succeeded, and the handle is to a view object.
Remarks
The MsiDatabaseOpenView function opens a view object for a database. You must open a view object for a database before performing any execution or fetching.

If an error occurs, you can call MsiGetLastErrorRecord for more information.

Note that it is recommended to use variables of type PMSIHANDLE because the installer closes PMSIHANDLE objects as they go out of scope, whereas you must close MSIHANDLE objects by calling MsiCloseHandle.

For example, if you use code like this:


MSIHANDLE hRec = MsiCreateRecord(3);

Change it to:


PMSIHANDLE hRec = MsiCreateRecord(3);

If the function fails, you can obtain extended error information by using MsiGetLastErrorRecord.

MsiViewExecute
The MsiViewExecute function executes a SQL view query and supplies any required parameters. The query uses the question mark token to represent parameters as described in SQL Syntax. The values of these parameters are passed in as the corresponding fields of a parameter record.


UINT MsiViewExecute(
MSIHANDLE hView,
MSIHANDLE hRecord
);

Parameters
hView
[in] Handle to the view upon which to execute the query.
hRecord
[in] Handle to a record that supplies the parameters. This parameter contains values to replace the parameter tokens in the SQL query. It is optional, so hRecord can be zero. For a reference on syntax, see SQL Syntax.
Return Values
ERROR_FUNCTION_FAILED
A view could not be executed.
ERROR_INVALID_HANDLE
An invalid or inactive handle was supplied.
ERROR_SUCCESS
The function succeeded.

Note that in low memory situations, this function can raise a STATUS_NO_MEMORY exception.


Remarks
The MsiViewExecute function must be called before any calls to MsiViewFetch.

If the SQL query specifies values with parameter markers (?), a record must be supplied that contains all of the replacement values in the exact order and of compatible data types. When used with INSERT and UPDATE queries all the parameterized values must precede all nonparameterized values.

For example, these queries are valid.

UPDATE {table-list} SET {column}= ? , {column}= {constant}

INSERT INTO {table} ({column-list}) VALUES (?, {constant-list})

However these queries are invalid.

UPDATE {table-list} SET {column}= {constant}, {column}=?

INSERT INTO {table} ({column-list}) VALUES ({constant-list}, ? )

If the function fails, you can obtain extended error information by using MsiGetLastErrorRecord.

How do services work?

Start ->Run -> services.msc. will list the services and it will be present in registry under this path
Hklm\system\ControlSet\Services\

How do u hide program name to appear in the control panel (Add/Remove Programs)

By Setting the public property ARPSYSTEMCOMPONENT = 1

What is a Custom Action?

To understand custom actions, you have to also understand sequences. An installation starts with a User Interface sequence where data is collected from the user, but nothing is changed on the target system. It then moves to the Execute sequence where there are no UI elements, but changes are made to the target system through various types of actions. So, what is an action?

Since Windows Installer installations are not controlled by a script (like InstallScript installations), there needed to be a way for developers to control the logic of an installation. This is facilitated by providing a set of standard and custom actions. An action in a Windows Installer installation is like a function in a program.

Now, actions are arranged in sequences, and sequences tell the Windows Installer the order to which actions are to be executed. The Custom Actions and Sequences view shows the sequences in an installation project. Next, we have to understand the types of Windows Installer installations.

There are three types of Windows Installer installations. There is Installation, Advertisement, and Administrative. In an Installation installation, the sequence is executed during a normal installation. In an Advertisement installation, the availability of an application is advertised, but not installed until requested. In an Administrative installation, an uncompressed source image of an application is created on a network. It's similar to the source image on a CD-ROM. Users can then install the product from this source.

The Installation and Administration installations both have User Interface and Execute sequences, but the Advertisement installation only has an execute sequence. But, let's get back to actions.

There are several types of actions. There is the Immediate action, Deferred action, Rollback action, and Commit action. Here are the differences.

An Immediate action is executed immediately and does not odify the target system, because there would be no rollback operations that can undo the changes.

A Deferred action will not be executed immediately when encountered but deferred to the installation script. Typical Deferred actions install files, modify the registry, etc.

A Rollback action is a special type of Deferred action. When the Windows Installer generates is script, it simultaneously generates a rollback script. The rollback script contains operations to be performed when the installation is rolled back. With custom actions, it is the developer's responsibility to provide a method to rollback system changes, since the Windows Installer would know nothing about the custom action.

A Commit action is a type of deferred action which is a complement to a rollback action. Commit actions are only executed at the end of a successful installation. There are placed in the installation script, but not executed until the end.

There is a lot more to all of this, but you have enough information to understand about custom actions. Custom Actions are simply a way to integrate custom code and data into a Windows Installer installation. Because after all, the Windows Installer is not all things to all people. It will probably not provide everything you need to do your installation. So, custom actions are a way to customize the installation for your own needs.

What's nice is that there are many types of custom actions. For example, you can create a custom action that just sets a property. Other types of custom actions are similar to functions, and can be written in VBScript or InstallScript. Also, new to InstallShield 2009 is the ability to write Managed Code Custom Actions. You can now write custom actions in your favorite language, C#, VB.NET, or something else. Very convenient.

Uninstall Information in the Registry

When you are developing and testing installations, you will at times make mistakes, an installation will fail, and the files will be partially installed onto your development machine. As a result, you won’t be able to uninstall your application, because everything is not working properly.

At these times, you can go to the Registry and manually delete the entries. When you do this, it will appear to Windows as if the application is not installed. Then, you will be able to go on with your business. So, where do you delete these entries?

You first need to go to the General Information view, Product Properties, and find the Product GUID property. If you wish, you can copy this GUID to the clipboard (minus the curly braces), then run Regedit, and search for it. But searching takes a while. So, in the registry, you can go to the following place and look for the GUID that matches your installation project.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

When you find this node, you can start your search for the Product GUID there. It will take no time at all, and when you find the node, you can just delete it. Then the next time you run your installation, to Windows and to InstallShield, it will appear as a first-time installation of your product.

Of course, after you delete the entry from the registry, you wll still have to manually delete the product files from your hard drive. You have to clean up after yourself.

Uninstalling run-time-created files

In a Basic MSI project, there are three ways to uninstall run-time-created files:

1. You can create a dummy file that has the same name as the file created at run-time. There doesn't have to be any information in the file. Generally, I just put the words "Dummy File" or "Placeholder" in the file and save it out. Add this file to a component in your installation, rebuild and test. The installer will install the file. When you run the application, it will overwrite the file. Then when you uninstall, the file will be deleted, because InstallShield installed it originally. Personally, I use this method almost exclusively. It works when you have a small number of files to work with.
2. You can create an InstallScript Custom Action which deletes the file or folder of files. Place a condition on the Custom Action such that it is only run during uninstallation. Then, add it to the User Interface sequence after ExecuteAction. This works. Some may not consider this very elegant, but it does work.
3. Add the file(s) to the RemoveFile table. This is a little more complicated, so you'll have to consult the InstallShield Help. If you are a Basic MSI or Windows Installer purist, you will probably like this solution the best.

That's it. Three ways to get rid of files created at run-time.

How to install SQL Server 2008 from a Basic MSI Project

SQL Server 2008 Express requires that the .NET Framework 3.5 SP1 and Windows Installer 4.5 be installed prior to it being installed. Windows Installer 4.5 had to be installed first. Windows Installer 4.5 has to be installed before .NET 3.5 SP1, or .NET 3.5 SP1 won't be installed. You won't get any errors if you install .NET 3.5 SP1 first when Windows Installer 4.5 is not already installed on the system. The problem will arise when you try to install SQL Server 2008 Express. It will just fail.

Here is the order of things.

Windows Installer 4.5 for Windows XP SP2 and later (x86)
Windows Installer 4.5 for Windows Server 2003 SP1 and later (x86)
Windows Installer 4.5 for Windows Vista and Server 2008 (x86)
Microsoft .NET Framework 3.5 SP1
Force a reboot of the machine

Microsoft SQL Server 2008 Express RTM (x86)
Main Product Install

You will have to add the prerequisites and then edit their order to get things right. Remember to force a reboot after the install of .NET 3.5 SP1. After Windows reboots, the install of SQL Server 2008 Express will take place, followed by your main product installation.

InstallScript vs. Basic MSI

InstallScript projects use the InstallScript language to control the installation. You may want to choose InstallScript and exploit the following features:

• The InstallScript language is easy to learn.
• In this project type, you can display full-screen billboards (background images).
• This project type makes use of the InstallScript language, which allows you to write a procedural installation rather than author a set of tables.
• The InstallScript installation type is easier to learn than the Basic MSI installation type. Actually, the learning curve for InstallScript is much less than that of Basic MSI.
• InstallScript allows you to perform actions before or after the main installation has run, meaning that InstallScript makes use of an event-driven model, which is useful if you're used to programming for Windws.
• You will have to work with InstallScript if you are given an existing InstallScript installation to maintain.
• InstallScript projects don't use the Windows Installer, which means your product can not be submitted to the Certified for Windows Vista Logo program.

Basic MSI projects use the Windows Installer service to run the installation. You will want to choose this project type for the following reasons:

• You want to submit your product to the Certified For Windows Vista Logo program. One of the main requirements is that you must use the Windows Installer for your installation.
• You don't want to use a scripting language for your installation.
• You have to work with Basic MSI if you are given an existing Basic MSI installation to maintain.
• You want to maximize compatibility with administrative tools such as Microsoft SMS.
• Your software will be customized by system administrators prior to release.
• You want to create transforms for the installation. A transform is used to modify an existing installation project.
• There is more of a learning curve associated with learning Basic MSI installation development.

If I were just learning how to use InstallShield, the first question I would ask is whether my company wants the Vista logo on it's product. If they want to meet the Certified For Windows Vista program requirements, then you have no choice but to use the Basic MSI project. End of story. In the end, Basic MSI installation development has more of a learning curve, while InstallScript installation development is pretty easy.

Troubleshooting Unnecessary Repairs

Sometimes you may encounter the problem of unnecessary repairs of MSI while launching the shortcut in the same logged in user. Here is the way to troubleshoot this problem.
You can go to eventviewr (by typing eventvwr in Run command) then to applications and check the latest error message after repair. It will tell you which component is missing and because of which MSI went for self heal.
You can now check out this component in your package and see what the problem is. Maybe your keypath is a moving target for that component.

There are other methods too which can be used in case the above does not work. These are Logs/Gap capture.

Using VBScript to Set Properties in MSI

We can easily use Set Property Custom Action to set Windows Installer Property, but sometimes we wish to set the property directly in VbScript, specially if we are taking an input from a user through VBScript. Hope this tip helps.

To set property through VBScript we can use "Session" object like:

Session.Property("ALLUSERS")="1"

or we can directly use Property keyword like:

Property("REBOOT")="ReallySuppress"

The only catch here is that we cannot set INSTALLDIR property through the above method as the package uses Directory table to store the value of INSTALLDIR. We need to write the below VBScript to set INSTALLDIR:

dim instpath

instpath = "C:\newpath\newfolder"

Session.TargetPath("INSTALLDIR")=instpath

Remember to place this Custom Action after CostFinalize if you are changing the value of INSTALLDIR property in UI Sequence.

Difference between self-heal and repair

Most people often think that self-heal and repair are the same thing, but they are two different things.

Self Heal is triggered by advertised shortcuts, or other advertising information in the package which eventually Repairs the application.

When the application is launched by advertised shortcut, it checks for all the key paths of the Current Feature, if any of the key paths is missing it will launch Repair.

Note that if there are multiple features then it will not check the missing key paths of the other features, but only the feature of which the advertised shortcut is launched.

Repair of an MSI can be triggered by

1) Repair button in Add/Remove programs

2) Giving the command line msiexec /f{other option} {MSI name}

Once the repair of the package is triggered, then the whole of the MSI is reinstalled. Then it does not see that only the feature which triggered the self heal should be repaired, but the whole MSI, by which I mean, all its features are reinstalled.

About Windows Installer properties

The following link provides you the best information you want to know about the Windows installer properties

http://helpnet.acresso.com/robo/projects/helplibdevstudio9/IHelpPropReference.htm