(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:
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:
Repair support for isolated files:
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:
Side-by-Side Assembly Type:
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.
Subscribing will provide email updates when this Article is updated. Login is required to Subscribe
Thanks for your feedback. Let us know if you have additional comments below. (requires login)
This will clear the history and restart the chat.