Packaging Questions For more information visit these sites: www.appdeploy.com www.wisesolutions.

com www.microsoft.com (search for windows installer) what is packaging? Why do u do it? Ans: packaging Is the process of creating a setup.exe with a developed code. Repackaging is converting this setup.exe to setup.msi by using windows installer technology with a tool like wise package studio or install shield. Why we do is?------refer ans 2. advantages of packaging? Ans: a) Easy deployment and maintenance b) Self repair of applications c) Remote installation d) Applications will not conflict with each other plus avoiding system crash e) Web deployment is possible. Packaging process? Ans: tech review of given setup.exe- setup capture scripting the wsi file obtained by setup capturecompiling and generating msi package validating msi and debugging errorsconflict management and deployment. What do u do when package is given? Ans: same as ans 3 use of registries? How many registry hives are their? Explain. Ans: registries are used to point to the files. They contain path of a file,from where to fetch the file and compress it into msi. Also registries are called when application is launched.applications reads the entries in the registries and fetches the files as and when required. Registry hives: HKCR,HKCU,HKLM, HKUsers HKCU—user specific registry HKLM--- Machine specific registry For detailed info go to start menuruntype regedit. what is the use of files? Ans: files are called when the application is running. There are various types of files like .exe, .ico, .ini etc. they are called associations. 7) What is difference between features, components and files? Ans: application contains many features, features contain components, and components contain files. Like this application is gathered. 8) what is ini file? What it does?
1

Ans: ini file is information file or initialization file. It is having some information required by the application during running. It can contain server name, registries values, path name, device name, system name anything, which changes frequently. 9) what is dll conflict? Ans: application tries to install the dll, which is already present in the machine this leads to dll conflict. To solve this we reference count dll’s by ticking the checkbox in the component. One more solution is to isolate the components in the application by using wise tool. 10) what is software distribution? Ans: software distribution is putting applications in central place so that it is available to all users. 11) what are various installations? Explain one with example. Ans: various installations: remote installation on demand installation wireless installation server installation Remote installation: admin sitting on one machine can install to 1000 machines across the network. 12) what is dependency? Ans: some applications are depending upon other applications like front end vb calling backend oracle. So here for vb application of this kind oracle is dependency. 13) what is custom action? Why we use it? Ans: custom action is nothing but special vb script or wise script written and called in between the package to do required task. Ex: to remove some services or registries etc. 14) what is meant by client standards? Ans: various clients have various requirements , like we want application name with version and name without version, we want these shortcuts, we don’t want these files in the package etc. 15) XP features—why we migrate applications from NT to XP? Ans: XP features which are not present in any other windows: system restore point application can’t touch the code kernel of XP-OS doesn’t need restart after installing most applications forward and backward compatability 16) what is msi? Ans: msi file is complete application, which actually contains the resources of the application like files, registries etc which are needed for the installation. 17) what is mst and use of mst? Ans: to make any customizations in the application and to implement business rules we create mst’s. mst is like cap on msi.
2

Ex for customization: u can decide how many shortcuts u want etc 18) what u get after capturing the application? Ans: capture means--- start wise tool and start capturing before installing the application which is to be packaged and install the application and again perform the same operation, now all changes to the system are recorded. this is capturing. After capturing u will get output as .wsi. by compiling this .wsi u get .msi. 19) what is difference between wsi and msi? Ans: wsi file ----- this we get immediately after capture, this is output of the capture process. Wsi file contains the information about from where files are to be taken or fetched and compressed to produce msi file. When u compile wsi file u get msi file as output. Msi file will be containing files physically compressed and put in it. Wsi is like a root map of application but msi is result of compiling wsi Ex: after compiling code we get exe file, same way we get msi after compiling wsi. 20) what is rollback? How u will handle it? Ans: if some problem occurs while installing the application, then instead of stucking in between the installation process, windows installer will rollback the installation and remove all that is installed. Means application is either installed fully or it is not installed at all. 21) what is uninstallation ? how u deal with it? Ans: uninstall is a process of removing everything which is installed. If some files or registries are remained even after uninstall they are removed by putting them in “remove file table”. 22) what is application repair i.e self healing. Ans: after installation when user is using application if some file is deleted accidentally windows installer will take that file and reinstall it to the user. i.e application is repaired automatically. This process is called self healing or repair. How does the self repair feature works? When an MSI entry point is triggered all files marked in the MSI as keypaths are verified to exist before execution. Each component in a feature contains one or more elements, one of which is marked as a keypath. When discovered to be missing, an installation is triggered at the feature level (for repackaged applications, this is often the entire package). Checks to verify if a file is the correct version, or if the file is corrupt is possible, but is not the default behavior. Such a check must be specified when the MSI is authored as to perform such a check of all files would be an intensive process that would affect system performance. 23) what are merge modules? Ans: These are the files with .msm extension, used by multiple applications. It contains various files, dll,ocx etc Ex: MDAC is a merge module. 24) Why do package keep reinstalling? Ans: If a key file is found to be missing on launch, Windows Installer will trigger a reinstallation of the parent feature. Having a "clean" package is key. To find out just what the problem is, look in your Application Event log. Or for more detail, turn on Windows Installer logging and search for the word "error" in the resulting log file (found in %TEMP%).
3

Some common reasons why this may occur: Missing Files or Registry Keys Look closely- some files are deleted by the application itself. If your package contains such a file it will self-heal in order to restore the file each time. Temporary Files Included In MSI If any temporary files left on the system are captured in your package, they may cause self repairs to occur in order to restore them. HKEY_CURRENT_USER Keys in Package HKCU Keys are installed only for the current user. Therefore, the first time the application is run by each user, the HKCU keys belonging to the package will not exist resulting in a reinstallation of the containing feature. 25) What operating systems come with Windows Installer? Ans: Microsoft Windows 2000, Windows Millennium Edition (Windows Me), and Windows XP include Windows Installer. Windows 2000 includes version 1.1 of Windows Installer, Windows Me includes version 1.2, and Windows XP includes version 2.0. Windows 2000 SP3 also contains version 2.0 of Windows Installer. Windows XP SP2 includes version 3.0. 26) How to specify files not be removed after uninstall? Ans: You may specify what files should not be removed during uninstall at the component level. However, the terminology differs between the Wise and InstallShield products: In Wise Package Studio: In the "Setup Editor" view, locate and right click on the component that contains the file you wish to have remain on the system after an uninstall operation. Select "Details" and then check the "Leave installed on uninstall" checkbox. In InstallShield AdminStudio: Choose "Components" from the "Organize Your Setup" tree on the left and select the component you wish to have remain on the system after an uninstall operation. Change the "Permanent" property of the component to "Yes". 27) How to see what public properties are available? Ans: Any properties listed in the property table that are written in CAPITOL letters are public properties that may be set from the command line. 28) How to control the destination directory of the package? Ans: By default an MSI will place itself on the drive with the most available free space. This can be controlled via the ROOTDRIVE public property. The ROOTDRIVE property specifies the default drive for the destination directory of the installation. If the Directory column of the Directory table indicates the root destination directory by a property name that is undefined, the installer uses the value of the ROOTDRIVE property to resolve the path to the destination directory. The value for this property must end with '\'. 29) Can we install device drivers with msi? Ans: The ServiceInstall Table allows for the installation and control of services to a limited degree. Not supported are: SERVICE_KERNEL_DRIVER (a driver service) and SERVICE_FILE_SYSTEM_DRIVER (a file system driver service.)
4

Repackaging hardware is problematic at best, the consensus seems to be that the creation of a custom action which performs the hardware installation via an INF file is the way to go. 30) What are the system requirements for install on demand features? Ans: Self repair only works with the “Desktop Update” from Microsoft, that means the shell32.dll needs to be version 4.72.3110.0 or higher. The application must also be launched from the Advertised Icon created by the MSI package- running the executable from File Manager or creating your own shortcut (.LNK) will bypass the Install-ondemand or repair process of the Windows Installer.

31) What is windows installer? Ans: The Windows Installer manages application installation, modification, repair and removal. It is both a command line utility and a service for the management of application installation on Windows systems. Windows Installer packages are self-contained database files containing requirements and instructions that are followed when applications are installed. Among several key benefits gained include:  Consistent installation rules  Better management of shared components  Dynamic configuration and control 32) How do I install only the features I want? Ans: The ADDLOCAL, ADDSOURCE, and ADVERTISE properties can be used to install only a certain number of known features. The following command-line script would be used to install the "Sports" and "News" features of the example.msi package locally on the machine. msiexec /i example.msi ADDLOCAL=Sports,News /qb The following command-line script would advertise the "Sports" feature and install the "News" feature to run from source. Msiexec /i example.msi ADVERTISE=Sports ADDSOURCE=News /qb Another important thing to remember is that feature names are case-sensitive. 33) What is a managed application? Ans: A managed application is an application where the system administrator exerts some level of control over the installation and maintenance of the product. Managed applications are often used to deploy software to large numbers of users or machines. Managed applications are a way for system administrators to allow users to install authorized software in locked-down environments where users generally do not have the rights to install software. An application is considered managed if it is: • Installed or advertised to a user by a member of the Administrators group. • Installed or advertised per-machine by a member of the Administrators group. • Assigned or published on Windows 2000 and later by an Administrator. • Marked as managed by another software and deployment management system. The exact method depends on the management system used, but generally requires an administrator's action.
5

An installation package cannot declare itself "managed." Whether or not an application is managed is controlled by the system administrator. Note that "managed" is different from "elevated." An elevated application is an application that can run with system privileges when installing. All managed applications are elevated, but applications can be elevated without being managed by means of the AlwaysInstallElevated policy. Due to its security implications, this policy is disabled by default and requires careful consideration before use. 34) What are the differences between a 'deferred' custom action and an 'immediate' custom action? Ans: Deferred custom actions can only be sequenced between the InstallInitialize and InstallFinalize actions in execute sequence tables. Immediate custom actions, on the other hand, can be sequenced anywhere within any of the sequence tables. Deferred custom actions cannot access the installation database. In fact, deferred custom actions have very limited access to the installation session because an installation script can be executed outside of the installation session that created it. Immediate custom actions have access to the installation database and can read and set installation properties, modify feature and component states, and add temporary columns, rows, and tables among other things. While both deferred and immediate custom actions can run in the context of the user initiating the installation, only deferred custom actions can run elevated using the system context. Deferred custom actions are not executed immediately. Instead they are scheduled to run later during the execution script. The execution script isn't processed until the InstallExecute, InstallExecuteAgain, or InstallFinalize action is run. 35) When should I use a deferred custom action instead of an immediate custom action? Ans: Deferred custom actions should be used when the custom action must make a change to the system or call another system service. Additionally, only deferred custom actions can run in an elevated context. If your custom action requires elevated privileges in order to run, your custom action needs to be marked as deferred. Note: Custom actions marked to run in the system context (msidbCustomActionTypeInScript + msidbCustomActionTypeNoImpersonate) will only run in the system context if the installation itself is elevated. Additionally, when making a change to the system by means of a custom action, you should also include a rollback custom action that can undo the change. 36) What are the differences between small, minor, and major updates? Ans: A small update is a product update that changes a few files or possibly adds some new content. A minor update is a product update that makes enough changes to warrant changing the product version for the product, whereas a major update is a product update with a large number of changes that warrants a change in the product code. This table summarizes what changes in each update and the possible distribution vehicles for each. It's sometimes easier to think of a small update as a "hotfix" or Quick Fix Engineering (QFE) update, a minor update as a service pack, and a major update as a product upgrade. Small and minor updates can be considered almost equal in that the only real difference is that a minor update has a change to the ProductVersion whereas a small update does not. The rules that they follow and application of the patch are the same. Application of small and minor update patches requires explicit reinstallations. Major updates are not subject to that limitation and a reinstallation is not required for patch application. Additionally small and minor update patches are limited in the changes that can be made to the feature-component structure for the package. Significant changes can be made to the feature-component structure in the scope of a major update.
6

37) How can I figure out why my package fails to install? Ans: There are three good troubleshooting methods for tracking down package installation problems. The first method is to ensure that your package is valid by running validation. Validation helps catch common installation authoring problems by identifying errors and warnings. Two tools can be used for validating an installation package, both are available in the Windows Installer SDK: MsiVal2 and Orca. MsiVal2 is a command line utility for validating a package. Orca provides a graphical user interface for validation and will also highlight invalid entries in the package. The second method is to use the application event log. Windows Installer will record successful and failed installation information in the application event log. The final method is to generate a verbose log file, and then analyze the verbose log file looking for the source of the error. A helpful utility for analyzing verbose log files is the WILogUtl.exe tool provided in the Windows Installer SDK. Logging can be enabled via Windows Installer logging policy or by appending "/L*v path to logfile" to your MSIExec command line.

To generate a detailed verbose log file through policy, use the following registry key: • HKLM\Software\Policies\Microsoft\Windows\Installe r • Set: Logging = REG_SZ voicewarmup • Set: Debug = REG_DWORD 0x7 Log files generated through the policy key will be of the form msiXXXXX.log in the user's %temp% folder. Note: Logging through the command line overrides any logging policy settings. 38) Every time I launch my application, Windows Installer performs an installation. How can I determine the cause of the on-demand installation? Ans: An easy way to determine the cause of an on-demand installation is to look in the application event log for MsiInstaller log messages of the form: Event Type: Warning Event Source: MsiInstaller Event ID: 1001 Description: Detection of product '{000C1109-0000-0000-C000-000000000046}', feature 'Example' failed during request for component '{00030829-0000-0000-C000-000000000046}' Event Type: Warning Event Source: MsiInstaller Event ID: 1004 Description: Detection of product '{000C1109-0000-0000-C000-000000000046}', feature 'Example', component
7

'{00030829-0000-0000-C000-000000000046}' failed. The resource 'C:\Progam Files\example\example.exe' does not exist. The first message (with event ID 1001) states which component was being installed. The component listed here is the component named in the Component_ column of the Shortcut table for the particular shortcut. The second message (with event ID 1004) indicates which component failed detection. Improved event logging in Windows Installer 2.0 has updated the message so that in most cases, the message identifies the actual resource that resulted in the failed detection. The component with the missing or damaged keypath is the component that is triggering the reinstallation. In the example above, the reinstallation is triggered because the resource 'c:\Program Files\example\example.exe' does not exist. You would then need to find out why the keypath does not exist—in this case, the user deleted it. 39) How can I determine whether Windows Installer installed my feature or component? Ans: Determining whether Windows Installer installed a particular feature or component is fairly easy. The answers can be found in a Windows Installer verbose log file. The first thing to look for is the logging of the InstallValidate action. This action will log the installed, request, and action states of each feature and component in the installation package. MSI (s) (5C:F4): Doing action: InstallValidate Action start 1:51:18: InstallValidate. MSI (s) (5C:F4): Feature: Example; Installed: Absent; Request: Local; Action: Local MSI (s) (5C:F4): Component: Example; Installed: Absent; Request: Local; Action: Local Action ended 1:51:18: InstallValidate. Return value 1. In the log file snippet shown above, the "Example" feature will be installed locally since its action state is local. Furthermore, the component "Example" will also be installed locally given its action state. 40) Why are my files not being removed during uninstallation? Ans: There are four common reasons for why files may not be removed during uninstallation: • The components to which these files belong are marked as permanent. (This is done through the Attributes column of the Component table.) • None of the components to which these files belong have component GUIDs. (The value for the component in the ComponentId column of the Component table is NULL). Components without GUIDs are not managed by Windows Installer. • If the keypath of the component has a shared DLL refcount, then the component will not be uninstalled. • If the component is installed in the system folder and at the time of uninstallation there is an external shared DLL refcount for any one file in the component, then the component will not be uninstalled.

41) Why are my folders not being removed during uninstallation? Ans: Folders are not removed during uninstallation because of one of the following reasons: • The RemoveFolders action is missing from the execute sequence table when both the
8

CreateFolder table and CreateFolders action are used. • The folders were not created by Windows Installer, therefore it will not remove them unless told to do so. • Resources still exist in the folder.

42) Why are my registry keys not being removed during uninstallation? Ans: The most common causes for leaving behind registry keys during uninstallation are: 1 The Registry table contains entries marked with the '+' sign. This directs the installer to leave . behind those registry keys during uninstallation. 2 In the InstallExecuteSequence table, the RemoveRegistryValues action is sequenced after the . UnregisterProgIdInfo and UnregisterMIMEInfo actions. The sequence of these actions needs to be reversed. The presence of some registry values written from the Registry table prevents certain ProgId, extension, and CLSID keys from being removed. 43) Why is the disk space consumed by the installation so much larger than the actual sizes of the files I am installing? Ans: Windows Installer calculates two types of space consumption: the space consumed with rollback, and the space consumed without rollback. The space consumed without rollback is the actual disk space consumed by the installation. The space consumed with rollback will include the space of the backup files necessary for supporting rollback during the installation. Additionally, Windows Installer calculates some of the overhead required for performing the installation. Included in the overhead is the space required for the installation script and the space requirements of the cached package. Furthermore, the installer runs from a temporary copy of the installation package during the installation. Both the space requirements of the installation script and the space requirements of the running copy of the package are temporary. These files are cleaned up after installation. Consider the following example where your installation package is around 80 kilobytes (KB) in size and you are installing a 4 KB file (Note: your numbers may vary depending on the cluster size of your hard drive): 89120 bytes (cached MSI, rounded to nearest cluster size of 4 KB) 89120 bytes (temporary working copy of MSI)8192 bytes (estimated script size) 4096 bytes (small file, rounded to disk cluster size of 4 KB) ---------------------176128 bytes = 172 KB 44) Why is Windows Installer prompting for a reboot? Ans: Windows Installer may prompt for a reboot if it installs over a file that is in use or the package explicitly requests that the installer reboot. It is easy to determine if Windows Installer prompts for a reboot because it installed over a file that is in use. The first step is to generate a verbose log file. In the verbose log file, look for the presence of the ReplacedInUseFiles property in the property dump. If this property is present with a value of 1, then the Installer will require a reboot because it overwrote an in-use file. To determine which file was in-use, scan the log file for "Info 1603" and "Info 1903" messages. The 1603 message will be logged by the InstallValidate action. For example:
9

MSI (s) (DC:DC): Doing action: InstallValidate Action start 19:55:42: InstallValidate. … Info 1603. The file d:\test\sample.exe is being held in use by the following process: Name: sample.exe, Id: 4068, Window Title: 'Sample'. Close that application and retry. Normally, this message coincides with the presentation of the FilesInUse dialog box. In silent UI cases, this dialog box will not be presented. Additionally, not all files that are in use will show up in the FilesInUse dialog box. The FilesInUse dialog box may not be displayed if the files in use are not executables, the process holding the files is the process invoking the installation, or the process holding those files is one that does not have a window title associated with it. The FileCopy opcode in the install script can also log the 1603 info message. In the above example, the log file contains: MSI (s) (DC:DC): Executing op: FileCopy(SourceName=sample.exe, SourceCabKey=sample.exe, DestName=sample.exe, Attributes=0, FileSize=2044928, PerTick=32768, , VerifyMedia=1, , , , , CheckCRC=0, Version=2.0.2600.0, Language=0, InstallMode=59244544, , , , , , ) … Info 1603. The file D:\test\sample.exe is being held in use. Close that application and retry. At the end of the script during cleanup, the following log file message identifies the culprit for the reboot: Info 1903. Scheduling reboot operation: Deleting file D:\Config.Msi\12544a31.rbf. Must reboot to complete operation. While the file is named 12544a31.rbf, it is the Sample.exe file. In order to install the file, the in-use file was renamed to the .rbf file and will be deleted upon reboot. 45) What does the ERROR_INSTALL_PACKAGE_VERSION error (1613) mean? Ans: The error ERROR_INSTALL_PACKAGE_VERSION means that the version of Windows Installer on the machine does not support the schema of the package. The package schema is indicated by the PID_PAGECOUNT property in the summary information stream of the package. If the schema number of the package is greater than the maximum supported schema by Windows Installer, you will need to update your version of Windows Installer or re-author the package to be compatible with an earlier schema. The minimum supported schema for all versions of MSI is 30. The maximum supported schema for each version of MSI is: • Windows Installer 1.0: 100 • Windows 110 • Windows 120 • Windows 200 Installer Installer Installer 1.1: 1.2: 2.0:

46) When launching an installation from a system account, I receive error 2103. Why? Ans: Launching an installation from a system account, like the scheduler service, may result in the 2103 error. This can occur if you are initiating a per-user installation. Only per-machine installations
10

are permitted from the system account because the system account does not have all of the necessary per-user profile folders. 47) Why do I receive error 2755 when launching an installation from a mapped drive letter on a terminal server? Ans: Windows 2000 and earlier operating systems do not support passing mapped drive letter information between terminal server sessions. Since Windows Installer service runs as a service in the console session, mapped drive letters established in remote sessions are not visible to Windows Installer service, resulting in this error. This only applies when running the service in Application Server mode, not Remote Admin mode. Note that this limitation no longer exists in Windows XP and later operating systems. 48] The product code must be changed if any of the following are true for the update:  Coexisting installations of both original and updated products on the same system must be possible.  The name of the .msi file has been changed.  The component code of an existing component has changed.  A component is removed from an existing feature.  An existing feature has been made into a child of an existing feature.  An existing child feature has been removed from its parent feature.  When using a version of the installer prior toversion 2.0, the product code must be changed if a component has been added to an existing feature. With version 2.0, and later versions, a component may be added to an existing feature without requiring a product code change. Note that adding a new child feature, consisting entirely of new components, to an existing feature does not require changing the product code.

Path Variables View This view and its subviews do not appear in the following project types:
• • • •

MSI Database MSM Database Transform Smart Device

The traditional way to link to source files in an installation project is to create a reference to that file using a hard-coded path. For example, you might have a source file called Program.exe located at C:\Work\Files that you want to include in your installation.
11

Using Hard-Coded Paths If you use hard-coded paths, you have to enter the entire path every time you want to associate a source file from that directory. If you move the file to another directory, you have to change the hardcoded path as it appears in your installation project. If your installation consisted of a small number of source files, this might not be a problem. Unfortunately, some installations contain thousands of files that all need to be remapped if you change the folder structure or migrate the project to a different machine. Using Path Variables Overview With path variables, you can define commonly used paths in a central location so that you do not need to change every source file's path each time you move the project or change the directory structure. In the previous example, if you keep all of your application's source files in various subfolders under C:\Work\Files, you could create one variable that points to the Files folder— <MyFiles>. If you want to include a file that is in C:\Work\Files\Images, you enter <MyFiles>\Images. If you move your files to D:\Work\Files, you can go to one place, your variable <MyFiles>, and change the folder that it points to. Using the Path Variables Explorer All path variables can be viewed and modified in the Path Variables explorer in the Path Variables view. You can use path variables in almost any location in InstallShield where you link to source files, such as in the Dialog Editor, dynamic file links, and the release location. Instead of entering the path variables yourself, you can have InstallShield recommend them whenever you browse to a path. NOTE Path variables are used during the development of your installation project. These paths do not apply to the target machines where the application is being installed. Rather, they are used to link to source files for your installation project. When the project is built, those links are evaluated and the files they point to will be built into the installation.

Path Variables Types There are four types of path variables that you can use. Each type functions somewhat differently from the others. Regardless of the path variable type you use, the variable name is provided in the same manner throughout InstallShield. Types of Path Variables Variable Type Predefined Description Predefined path variables are path variables that point to some of the most commonly
12

Path Variables

used folders. Unlike other types of path variables, these values cannot be edited in InstallShield.

See Registry The values of registry-based path variables are derived from the registry keys you Path Variables created. After creating the registry key, you need to set a path variable to this key. Environment Variables Environment path variables are based on the values of your system's environment variables. You can set an environment path variable to an existing environment variable.

Standard, or user-defined, path variables are defined through InstallShield. You can Standard Path specify a path variable such as <MyFiles> with a value of C:\Work\Files. These Variables variables do not rely on any outside sources, such as the registry or system paths.

MSI (s) (3C:CC) [07:52:18:321]: Feature: CitiAudit; Installed: Absent; Request: Local; Action: Local MSI (s) (3C:CC) [07:52:18:321]: Feature: Complete; Installed: Absent; Request: Local; Action: Local

13

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.