Application isolation keeps the applications protected from inadvertent overwrites by other applications if they are using only local resources and DLLs. Isolating an application with its support files ensures that your application always uses the version of shared files with which it was installed.  

1. Application isolation is one solution to component versioning conflicts, or DLL hell.
2. Isolation reduces versioning conflicts by modifying an application so it always loads the versions of components – such as DLLs – with which it was originally developed and tested.
3. Application isolation provides increased stability and reliability for applications because they are unaffected by changes caused by installation and ongoing maintenance of other applications on the system.
4. Resolve incompatibilities between different versions of shared components.
5. Reduce the complexity of the installation by storing COM activation data in a manifest instead of the registry.
6. Insulate the application from changes to shared components.

How to isolate an application.

Application isolation can be performed using one of these two methods.

• Assemblies and manifests
• MSI isolated components

Assemblies and Manifests:

Application isolation using assemblies and manifests is the recommended isolation method for Windows XP. Assemblies are DLLs or other portable executable files that applications require to function, and manifests are XML files that describe either an isolated application or an application's assemblies. These assemblies and manifests provide the same end result as Windows Installer isolated components, but keep all information outside of the registry and do not require the components to be installed in the same folder as the application. This reduces the chance of errors after isolation resulting from how the application was written.

MSI Isolated Components:

Application isolation using Windows Installer isolated components is best applicable for Windows 98 SE, Me, and 2000. It can also be used on Windows XP, but using assemblies and manifests is the better solution. The isolated component method copies shared files (typically DLLs) into an application's folder instead of a shared location. The application then uses these files instead of global ones, preventing modifications made by other applications from affecting the shared files. As a result, the application always uses the versions of these files with which it was deployed.
When an application is isolated, any shared files are moved to an area specified during the package building. That area is normally the application directory. An Isolated Component table is populated with the information that the OS needs to find the redirection. The Isolated Component table is part of the Windows Installer database created during repackage creation. When the application is setup, a .local file is created from the Isolated Component table and directs the OS to search for the needed DLL files in the application directory.Disadvantages of .local(Isolated Component Method)

• Only DLLs present in the same feature as the executable can be isolated using this method. If DLL is present in different feature then it needs to be moved to the main exe feature.
  
  • No self-repair functionality exists for isolated.DLL files in the application directory.
  • 16-bit applications cannot be isolated using .LOCAL isolation method.
  • Only DLLs present in the same feature as the executable can be isolated using this method. If DLL is present in different feature then it needs to be moved to the main exe feature.