Resolving Conflicts with the Application Isolation Wizard

Products

• Symantec Products

Issue/Introduction

 

Resolution

Question
How can I use the Application Isolation Wizard to reduce the threat of application conflict?

Answer

(Note: This article was originally published in the February 2003 TechInfo! Newsletter. The information contained in this article is accurate for the products referenced and has not been updated for later product releases.)

Conflicts between applications that share files are a common roadblock to successfully deploying applications. You can resolve these types of conflicts by isolating applications. Isolation offers a mechanism to correct shared resource conflicts that could otherwise not be resolved through typical practices. The Application Isolation Wizard in Wise Package Studio contains several options that let you isolate applications in an optimal manner for your environment.

There are two primary forms of isolation supported by the Application Isolation Wizard:

• .LOCAL isolation, which is natively supported by the Windows Installer service
• .NET isolation, which functions on the Windows XP and .NET Server platforms only

This article describes both of these isolations methods.

Understanding .LOCAL Isolation

Support for .LOCAL isolation is built into Microsoft's Windows* 98, ME, Windows 2000, XP, and .NET Server operating systems. This support forces the search order for a .DLL file to look first in the application directory. When Application.exe and a 0-byte file named Application.exe.local exist in the same directory, calls made by the executable are forced to look first in the application directory for .DLL files used by that .EXE.

Because .LOCAL isolation assumes that the application was written not to support isolation, it redirects hard-coded calls as well as cascaded calls, calls made in and out of shared resources, and fully-pathed COM registrations.

Even though .LOCAL isolation is very powerful and works with the majority of available applications, applications that require shared memory spaces and 16-bit applications cannot be isolated using this method.

How .LOCAL Isolation is implemented within Windows Installer

The Windows Installer service natively supports .LOCAL isolation with the IsolatedComponent table and IsolateComponents action. If a file is not present, Windows Installer installs each isolated .DLL in the shared location. If any version of the .DLL exists in the shared location, it is not overwritten. Instead, a copy of the isolated .DLL is placed in the application directory. A 0-byte .LOCAL file is created for each .EXE file with an isolated .DLL. When a shared .DLL is used by multiple executables, the .DLL is isolated to each .EXE in the package.

There are two limitations of the .LOCAL support within Windows Installer. .DLL files can only be isolated to executables contained within the same feature as the shared resource. The .DLL must be included in the same feature as the executable. Additionally, no self-repair functionality exists for isolated .DLL files in the application directory. If an isolated .DLL in the application directory is removed or becomes corrupt, the .MSI does not repair the missing file. To circumvent these limitations, use options provided in the Application Isolation Wizard.

Feature Options in Application Isolation Wizard:

• Move files into the same feature as necessary and then isolate. This option moves all components containing .DLL, .OCX and .EXE files into a new parent-level hidden feature named Isolation_Wizard_Feature. Each .DLL is isolated against all executables within the MSI.
• Isolate only those files that are already in the same feature as the application .EXE. Select this option if you do not want to modify the feature-component structure of the .MSI. If this option is selected, .DLL files are only isolated to the .EXE files within the same feature.

Repair support for isolated files:

• Do not add repair support for isolated files. Use this option to accept default Windows Installer behavior. The isolated .DLL is installed to the shared location if not there, and a copy is installed to the application directory. The copy of the .DLL in the application folder does not self-repair if missing.
• Install isolated files in their original location. Select this option to add self-repair support for the isolated copy of the .DLL while still installing the .DLL to the shared location. This creates additional Windows Installer component registrations that point to the isolated copy of the .DLL.
• Install isolated files in the application directory only. Select this option to add self-repair functionality for the isolated .DLL by redirecting the installation of the .DLL from the shared location to the application directory. This prevents a copy of the .DLL from being installed to the shared location regardless of whether the .DLL is already in the shared location.

Understanding .NET Isolation

In Windows XP, use .NET isolation as another method of isolation. .NET isolation works for applications and .DLL files that adhere to the .NET architecture for dedicated (non-shared) resources and follow .NET architecture on Windows XP and .NET Server. Older applications that contain fully-pathed and hard-coded .DLL calls are not redirected and cannot be successfully isolated using .NET isolation.

Because the .NET architecture is relatively new, .NET isolation may not work for a majority of applications. While .NET isolation is a more thorough method of isolation, the application must be programmed in accordance with the .NET architecture. As with .LOCAL isolation, .NET isolation redirects cascaded calls, calls made in and out of shared resources, and fully-pathed COM registrations. The .NET methodology uses manifests to isolate COM registration and uses versioned registry keys to isolate registry data. This level of isolation is unattainable with the .LOCAL method of isolation.

The Application Isolation Wizard isolates files by installing the isolated .DLL to the application directory. Manifest files created for both the .DLL file and the .EXE file are named DLLName.DLL.manifest and EXEName.EXE.manifest, respectively. These manifest files are XML files that contain information describing the assemblies and their dependencies. Windows uses the information in the manifests to redirect calls.

The Application Isolation Wizard offers three additional options for .NET isolation.

Operating System Support:

• Support Prior Operating Systems. Select this option to create duplicate Windows Installer components for isolated .DLL components without the XML manifest data. The components are conditionally installed to the shared location based on the operating system running on the target computer.
• Support Windows XP Only. This option moves all isolated .DLLs to the application directory. The isolated .DLL is not installed to the shared location.

Side-by-Side Assembly Type:

• Create private side-by-side assemblies in application directory. This option isolates .DLL files to the application directory.
• Create shared side-by-side assemblies in WinSxS directory. This option isolates .DLL files to the WinSxS folder so other applications can share the .DLLs. Be sure the files and manifests placed into the WinSxS folder are digitally signed. To sign these files, you need to provide the certificate, credentials and private key files.

Place copy of isolated files in their original location for applications not written to support isolation. Mark this check box to install a copy of the isolated .DLL to the shared location even if the operating system does not support .NET isolation.

When using either .LOCAL Isolation or .NET Isolation with the Application Isolation Wizard, the files to be isolated can be selected manually or automatically. No matter what option you select, the Application Isolation Wizard performs all isolation automatically with no need to directly edit the .MSI file. The Application Isolation Wizard tool allows you to quickly isolate applications in a manner that is appropriate for your environment.