Dear Readers, Welcome to Application Packaging Interview Questions and Answers have been designed specially to get you acquainted with the nature of questions you may encounter during your Job interview for the subject of Application Packaging. These Application Packaging Questions are very important for campus placement test and job interviews. As per my experience good interviewers hardly plan to ask any particular questions during your Job interview and these model questions are asked in the online technical test and interview of many IT companies.
Process of creating an installer for an application is called application packaging. Usually in it binary files provided by developers are packaged to form a package. The Main difference between packaging and re-packaging is that the source files does not come in the form of package in packaging where as in re-packaging they come in a form of a package, which might be MSI or legacy package (such as executable, batch files, etc).
Repackaging (Customized Installation) is the process of capturing the changes made by an Installation Program (Package) and it is customized to support company standards and distribution methods.
It is not necessary to do setup capture to call it repackaging, even creating must files or is files can be called application repackaging.
Ø Review the packaging requirements (User Requirement Review).
Ø Analyze the vendor package (Tech Review).
Ø Repackage the application (Setup capture).
Ø Customize the package (Scripting).
Ø Test the package (Testing & UAT).
Ø Release the package to end users (Deployment).
Most common reasons for Re-packaging are as follows
Ø Customized Installation.
Ø Reduce Support Costs.
Ø Self Repair.
Ø Source Resiliency.
Ø Unattended Install.
The problems with Legacy Installations.
Ø High Support Costs.
Ø Fragile Installs & uninstalls.
Ø Difficult & labor Intensive to deploy.
Ø Wise for Windows Installer.
Ø Wise Package Studio.
Ø Install Shield.
Ø SMS Installer.
Ø WIX (It cannot be used for re-packaging).
Ø Visual Studio.
Ø Wise Package Studio
Ø Install Shield
Ø SMS Installer
Ø CA DSM
Ø Altiris Client Management Suite
Ø Altiris Notification Server Console
Ø Microsoft Systems Management Server (SMS)
Windows Installer (previously known as Microsoft Installer) is a built-in Operating System service for Installing and Managing Applications. It provides a standard method for developing, customizing, installing and updating applications. It is an engine for the installation, maintenance, and removal of software on modern Microsoft Windows systems. The installation information, and often the files themselves, are packaged in installation packages, loosely relational databases structured as OLE COM Structured Storages and commonly known as “MSI files”, from their default file extension. Windows Installer contains significant changes from its predecessor, Setup API. New features include a GUI framework and automatic generation of the uninstallation sequence. It is positioned as an alternative to stand-alone executable installer frameworks such as older versions of InstallShield and Wise Package Studio (later versions of both supports Windows Installer) and NSIS.
Ø Installation on Demand
Ø Repair (Self-healing)
Ø Rollback (Transactional operations)
Ø Managed Shared Resources
Acquisition: The Installer first installs the feature and then progresses through the actions specified in the sequence tables of the installation database. These actions query the installation database and generate a script that gives a step-by-step procedure for performing the installation.
Execution: The installer passes the information to a process with elevated privileges and runs the script.
Rollback: If an installation is unsuccessful, the installer restores the original state of the computer. When the installer processes the installation script, it simultaneously generates a rollback script. In addition to the rollback script, the installer saves a copy of every file it deletes during the installation. These files are kept in a hidden,system directory. Once the installation is complete, the rollback script and the saved files are deleted.
MSI is “Microsoft Windows Installer”. It is an installation, in the form of a single file. It is actually a database that contains several tables (80+). Each of these tables contains instructions and set-up information.
Ø Products (Collection of Features)
Ø Features (Collection of Components)
Ø Components (Collection of files and Registries)
A single, installed, working program (or set of programs) is a product. A product is identified by a unique GUID (the ProductCode property). A product is not the same as a package: a single MSI package might install multiple different products. For example, an MSI might install French and English versions of a program, each of which is a different product.
Features are buckets for Components. Windows Installer configuration commands operate only on Features (installing, advertising, Uninstalling). Self-healing, installon- demand and user profile fix-up operate at the Feature level.
Components are collections of resources that are always installed or removed as a unit from a user's system. A resource can be a file, registry key, shortcut, or anything else that may be installed. Every component is assigned a unique component code GUID.
When an MSI-based application is launched (by clicking on an advertised shortcut or file type association), Windows Installer checks the existence of key path items. If there is a mismatch between the current system state and the value specified in the MSI package (e.g., a key file or registry is missing), then the related feature is reinstalled. This process is also known as self-healing or self-repair.
The Microsoft Windows Ins taller provides many built- in actions for performing the ins tallation process. For som e cases the developer writes an action to execute his own installation is called Custom Actions.
The windows Operating System recognizes file types and as sociates them with programs bas ed on their files extens ion. A file that carries no extension or no associated program is called Orphaned.
Shortcuts are the entry points to the applications installed on the system which is normally points to a file:
Ø Advertised (File should be Installed by the Application).
Ø Non Advertised (File that is not part of Installation. It is also called Command Line shortcuts).
INI files are plain-text files that contain configuration information. "INI" stands for
A windows service is a background process which is loaded by the Service Control Manager of the OS.
Ø Win32 Service (Win32 services are the services which is running by the executable file installed by the Application).
Ø System or Kernel Services (Kernel services are the services which are used by the OS to communicate to the hardware devices).
Most of the Service information are stored under the windows registry hive “HKLM\System\CurrentControlSet\Name of the Service”
Ø Service Install (Service Details)
Ø Service Control (Controlling the service during Installation & Un Installation)
ODBC means Open Database Connectivity. The purpose of ODBC is to allow the user to access data from any application. The layer between the application and the DBMS called DSN.
Ø System DSN (DSN will be available for all users)
Ø User DSN (DSN will be available for that particular user)
The Windows operating system recognizes file types and associates them with programs based on their file extension. A file that carries no extension or no associated program is called Orphaned.
Environment Variables are the variables that are set by the Operating System & Application.
Ø System Variable (Available for all users)
Ø User Variable (Available for that particular user)
System Variables: HKLM\System\Current Control Set\Control\Session Manger\Environment
User Variables: HKCU\Environment
Merge modules are a mechanism in Windows Installer that allows companies to prepackage and share standard component definitions. Merge modules are used to deliver shared code, files, resources, registry entries and setup logic to applications as a single compound file.
If there are a number of applications that require a specifically configured component, it would be possible to create a merge module that installs and
configures that component. That merge module could then be added to the installation packages of each product that required that particular component.
This saves the effort of having to individually add the necessary files, registry entries, and other components to every installation. It also saves time if updates are needed, as instead of updating the installations for all five applications, only the merge module is updated, and the installations only need to be rebuilt.