Application Isolation: Deep Discussion
Windows supports the use of shared libraries, usually DLLs and OCXs, to reduce memory and disk-space requirements for applications, and to help developers with modular application development. However, when many applications are installed on a system, using shared libraries can lead to application instability. Common problems include the following:
- Newer versions of a library may not be backward compatible with earlier versions.
- Similarly, older versions of libraries may contain bugs that applications have worked around; When a newer version is released, the workaround fails.
- Poorly written legacy installers can overwrite a newer version of a library with an older version.
- Poorly written Uninstallers can uninstall libraries required by an application that remain on the system.
These and other problems are commonly called DLLHELL.
Windows Installer minimizes some of these problems. MSI enforces strict file-Overwrite rules, so a newer version of file will not be overwritten by an older one. Its self-repair features can lessen the effects of an uninstaller removing a file still required by another application.
Moreover, newer versions of Windows have introduced features that enable an application and its dependent libraries to be installed to the same directory, so an application can be installed with DLL versions known to work with the application. Using application isolation features can be useful if, for example, the conflict -identification process identified different versions of the same file being used by multiple applications.
To help your repackaged application utilize these new windows features, the Wise tool provides the Application Isolation wizard. The following sections describe the application isolation features of different versions of windows,and then how to use the Application Isolation Wizard.
Application Isolation Techniques
The two application isolation techniques are DLL/COM redirections, supported by Windows 2000 and later, and WIN32 Assemblies, supported by WindowsXp.
DLL/COM Redirection
Windows XP and Windows 98 second edition support a feature called DLL/COM Redirection (Sometimes just "DLL Rediretion", or "Isolated components"). Where an executable and its DLLs can be installed to the same directory, and Windows will use the copies of the DLLs in the executable directory. To enable the DLL redirection, one creates a "Redirection file", which is an empty (Zero-byte) file named after the application with extension "Local"appended to it, in the application directory for an executable called "sample.exe", the Redirection file would be named "Sample.exe.local".
In addition, the Redirection file specifies that a COM server (self-registering DLL or OCX ) in the application directory should be used, irrespective of the full registered path of the library in the target system's registry.
Windows Installer supports DLL/COM redirection using the isolated component table in MSI database, along with the standard Isolate components action. Using MSI for DLL/ COM redirection requires the executable and a library to isolate to be located in components inside the same feature.
Win32 Assemblies
In Addition to supporting DLL/COM Redirection, Windows XP supports a second type of isolation using Win32 assemblies. A win32 assembly is an executable or DLL with a manifest file-a specify formatted XML text file - describing the assembly's dependencies. The main advantage of using Win 32 assemblies is that can be installed without writing COM data to the registry, ideally making the application and its libraries completely self-contained.
The two types of manifests used in Win32 assemblies are application manifests and assembly manifests. An application manifest contains an application's name and version information, and the names and COM information for its dependent libraries( An application manifest file should be named AppName.exe.manifest.) The other type of manifest, an assembly, is a manifest for a DLL or OCX file, containing the library's file name, version, and COM information. Every manifest contains an assembly identity. An assembly identity is a name of the form OrganizationName.DivisionName.AssemblyName. Unlike application manifest, which are named after an executable, assembly manifests are named after the assembly identity with the extension ".manifest" appended, as in:
- OurCompany.AppMigration.AssemblyName1.manifest
On windows Xp systems, the application, dependent libraries, and manifest files should all be placed in the same directory. When the user launches the application, it will use the dependent libraries contained in the same directory.
Steps to describe how to implement isolation using WPS.
- Invoke the Application Isolation wizard from the side pane of Wise package studio
- Browse the .WSI or .MSI file on which the isolation has to be performed.
- Choose on the isolation method and the isolation type. The next screens depend on the options selected here.
- Choose how the process of isolation has to be taken place.
- Isolation is ready to be performed.
- The updated Windows Installer file can be either the default MSI file appended with _isolated or a new MSI file or a MST file.
A similar post has already been made by vijay raj. Please refer to Application Isolation: Basics and Directions for more practical knowledge.
- Login or register to post comments
- 1242 reads
- Printer-friendly version
















Cool..stuff really Deep discussion
Cool..stuff really Deep discussion