Check and get list of existing AppPools and Websites on a machine for IIS 7.0

I have been using Installshield for so long, but tasks related to IIS 7.0 found to be most amazing, as it make me learn about IIS quite a lot. I got introduced with AppCmd.exe which is a single command line tool for managing IIS 7. AppCmd enables us to easily control the server without using a graphical administration tool and to quickly automate server management tasks without writing code.

Some of the things you can do with AppCmd:

1. Create and configure sites, apps, application pools, and virtual directories
2. Start and stop sites, and recycle application pools
3. List running worker processes, and examine currently executing requests
4. Search, manipulate, export, and import IIS and ASP.NET configuration

I had a requirement in one of my web project, for showing users a list of available App Pools and Web-sites for selection. Using vb-script found to be little uncomfortable, but AppCmd.exe makes my life easy.

Note: AppCmd.exe is located in the %systemroot%\system32\inetsrv\ directory. Because it is not path of the PATH automatically, you need to use the full path to the executable when executing commands like in "%systemroot%\system32\inetsrv\AppCmd.exe list sites". Alternatively, you can manually add the inetsrv directory to the path on your machine so that you can access AppCmd.exe directly from any location.

List of App Pools can be get by using command: "AppCmd.exe list apppool".

Similarly we can get the list of available websites: "AppCmd.exe list site".

We can take the output of the above commands in a text file, and can read the AppPool list. Similary we can do for Website.

Check existence of any program installed on a machine through registry

Hi, reading this post? It means you are really looking for how to check for existence of MS Office or any other program via script, or through registry. There are some standard locations in the registry editor, where you could manually search for existence of some program installed on the local machine. But not everyone is comfortable with it. Also, there are chances of any accidental deletion of any wrong key, if done by some immature user.

But when it comes to script, and especially from checking within the installer, then we had some options:

1. System Search View: The system search view provides the Windows Installer capability to search for a particular file, folder, registry key, .ini file, or .xml file value on an end user's sytem prior to installation. this view is location in the left pane of the Installshield IDE, as shown in the image below:
   
   
   
   When you do right-click in the right pane as shown in the image below, a system Search Wizard opens which guides you to specify your search options for any Files, Folders, Registry Entries, and so on...
   
   
   
   
   You can specify your options according to your requirement.
   
   
2. Installscirpt Code: Another option we have is through installscipt code. We need to specify a key to search in registry. There are some in-built installscript functions which can help you in accessing registry details. One of such function of our use at the moment is RegDBKeyExist(szKeyRoot) which checks for the key in the registr yspecified by parameter szKeyRoot.
   
   A typical example for your best understanding is given below which could check for existence of MS Office on the target machine.
   
        szKeyRoot="SOFTWARE\Wow6432Node\Microsoft\Office\Word\\";  \\key to search in registry 
       // get the registry value
       nResult = RegDBSetDefaultRoot( HKEY_LOCAL_MACHINE );
       if (RegDBKeyExist (szKeyRoot) < 0) then 
            return FALSE;
      else
            return TRUE;
      endif;
   
   Hope the above content will be helpful to you. In case you have some query, then please feel free to put some comments on this post, or reply to me.

Checking whether IIS 7.0 exist on a machine

Hi, This article will help to check if IIS 7.0 or lower version is installed on the target machine. There are several ways to check, both manually and through custom code by searching in registry.

1. Go To Start -->  Run. Type inetmgr and press OK. If you get an IIS configuration screen, it is installed, otherwise it isn't.
2. You can also check ControlPanel->Add Remove Programs, Click Add Remove Windows Components and look for IIS in the list of installed components.

To Reinstall IIS.

Control Pane -> Add Remove Programs -> Click Add Remove Windows Components Uncheck IIS box Click next and follow prompts to UnInstall IIS. Insert your windows disc into the appropriate drive. Control Pane -> Add Remove Programs -> Click Add Remove Windows Components Check IIS box Click next and follow prompts to Install IIS.

There are such situations in which you need to check IIS existence from the installshield using code, then you need to search for its registry on the target machine. For a helping deed, I am presenting an example below:

szKeyRoot="SOFTWARE\\Microsoft\\InetStp\\Components\\";     //key to search in registry
// Set the Default root
nResult = RegDBSetDefaultRoot( HKEY_LOCAL_MACHINE );
    
if (RegDBKeyExist (szKeyRoot) < 0) then 
  return FALSE;
else
    return TRUE;
endif;


The return value will determine whether IIS 7.0 exist or not.

MsiDoAction

MsiDoAction is used in Basic Msi type projects, where we are not having events like OnFirstUiBefore like we have in Installscript based projects. To call a custom action, we need to use this function.


The MsiDoAction function executes a built-in action, custom action, or user-interface wizard action.
Syntax

UINT MsiDoAction(
  __in  MSIHANDLE hInstall,
  __in  LPCTSTR szAction
);
Parameters:
hInstall [in]
Handle to the installation provided to a DLL custom action or obtained through MsiOpenPackage, MsiOpenPackageEx, or MsiOpenProduct.

szAction [in]
Specifies the action to execute.

Return Value:
ERROR_FUNCTION_FAILED
The function failed.

ERROR_FUNCTION_NOT_CALLED
The action was not found.

ERROR_INSTALL_FAILURE
The action failed.

ERROR_INSTALL_SUSPEND
The user suspended the installation.

ERROR_INSTALL_USEREXIT
The user canceled the action.

ERROR_INVALID_DATA
A failure occurred while calling the custom action.

ERROR_INVALID_HANDLE
An invalid or inactive handle was supplied.

ERROR_INVALID_HANDLE_STATE
The handle state was invalid.

ERROR_INVALID_PARAMETER
An invalid parameter was passed to the function.

ERROR_MORE_DATA
The action indicates that the remaining actions should be skipped.

ERROR_SUCCESS
The function succeeded.

The MsiDoAction function executes the action that corresponds to the name supplied. If the name is not recognized by the installer as a built-in action or as a custom action in the CustomAction table, the name is passed to the user-interface handler object, which can invoke a function or a dialog box. If a null action name is supplied, the installer uses the upper-case value of the ACTION property as the action to perform. If no property value is defined, the default action is performed, defined as "INSTALL".

Actions that update the system, such as the InstallFiles and WriteRegistryValues actions, cannot be run by calling MsiDoAction. The exception to this rule is if MsiDoAction is called from a custom action that is scheduled in the InstallExecuteSequence table between the InstallInitialize and InstallFinalize actions. Actions that do not update the system, such as AppSearch or CostInitialize, can be called.

Deffered Custom Actions

Deferred Execution Custom Actions:
Deferred custom action's purpose is to delay the execution of a system change to the time when the installation script is executed. This differs from a regular custom action, or a standard action, in which the installer executes the action immediately upon encountering it in a sequence table or in a call to MsiDoAction.

The installer does not execute a deferred execution custom action at the time the installation sequence is processed. Instead the installer writes the custom action into the installation script. The only mode parameter the installer sets in this case is MSIRUNMODE_SCHEDULED. See MsiGetMode for a description of the run mode parameters.

A deferred execution custom action must be scheduled in the execute sequence table within the section that performs script generation. Deferred execution custom actions must come after InstallInitialize and come before InstallFinalize in the action sequence.

Custom actions that set properties, feature states, component states, or target directories, or that schedule system operations by inserting rows into sequence tables, can in many cases use immediate execution safely. However, custom actions that change the system directly, or call another system service, must be deferred to the time when the installation script is executed.

Because the installation script can be executed outside of the installation session in which it was written, the session may no longer exist during execution of the installation script. This means that the original session handle and property data set during the installation sequence is not available to a deferred execution custom action.

How to read assembly version of a file.

Hello Friends, today I have a POC to work on i.e. get the version information of an assembly and to update it in a config file. This can be easily done in Dotnet, but in Installshield one should know the inbuilt function, which returns the numeric version information of the specified file.


Function Name: VerGetFileVersion
Syntax
VerGetFileVersion(szFileName,svVersionNumber)


Help:
Please refer to Installshield Help for more details.