Isolated Applications

Isolated applications are self-describing applications installed with manifests. Isolated applications can use both private assemblies and shared assemblies.

An application is considered fully isolated if all of its components are either shared side-by-side assemblies or private assemblies. It is called partially isolated if it uses some components that are not side-by-side assemblies. Note that if an application uses some components that are not side-by-side assemblies, or uses private assemblies, the application may be affected by the installation or removal of other applications on the system. For more information, see Side-by-side Assembly Sharing.

Developers are encouraged to design isolated applications and to update existing applications into isolated applications for the following reasons:

  • Isolated applications are more stable and reliably updated because they are unaffected by the installation, removal, or upgrading of other applications on the system.
  • Isolated applications can be designed so that they always run using the same assembly versions with which they were built and tested.
  • Isolated applications can use functionality provided by the side-by-side assemblies made available by Microsoft. For more information, see Supported Microsoft Side-by-side Assemblies.
  • Isolated applications are not tied to the shipping schedule of their side-by-side assemblies because applications and administrators can update the configuration after deployment without having to reinstall the application. This would not apply in the case where only one version of the assembly is being made available.
  • A fully isolated application may be installed by using the xcopy command. Windows Installer can also be used to install an isolated application without impact to the registry. For more information, see Installation of Win32 Assemblies.

In some cases, existing applications can be updated into an isolated application without having to rewrite the application code. An application manifest can be created that describes the application's dependencies on side-by-side assemblies. If the application uses components that are not side-by-side assemblies, these may be deployed as private assemblies. Note that the possibility of doing this with third-party components may depend on licensing because the component will need to be authored as an assembly. For example, by creating an application manifest and specifying a dependence on the side-by-side common controls (COMCTL32), an application running on Windows XP can take advantage of Windows theming. You should always test your application to ensure it is compatible with the new version of the COMCTL32 assembly.

It may not be possible to update every existing application into a fully isolated application. For example, some Windows File Protection (WFP) system assemblies are not available as side-by-side assemblies and cannot be installed with the application as a private assembly. It may be possible to partially isolate such applications by specifying side-by-side assembly dependencies for some of the application's assemblies in an application manifest.

Send comments about this topic to Microsoft

Build date: 10/29/2009

Tags :


Community Content

linearred
WinSxS assemblies override private assemblies by default
It should be noted that the default behavior of the loader is to first check the WINDOWS\WinSxS folder for the identical version or a superseding version of a dependency identified in an application manifest, and to use that version regardless of whether or not a private assembly containing the dependency has been provided with the application.

Superseding versions are determined by checking the dependency's associated policy file (aka "Publisher Configuration File") in the WINDOWS\WinSxS\Policies folder for "bindingRedirect" elements that redirect the loader to substitute a specific (usually later) version of a file for one or more other (usually earlier) versions of the file.

For Publisher Configuration File (aka "policy file") information, see:
http://msdn.microsoft.com/en-us/library/aa375682(VS.85).aspx

The documentation states that the behavior of using "found" WinSxS versions can be overriden by supplying an "Application Configuration File" for the referencing EXE or DLL in question. The file must be installed in the same location as the application manifest for the EXE or DLL, which might be stored as a resource in the dll or executable.

For Application Configuration File information, see:
http://msdn.microsoft.com/en-us/library/aa374182.aspx

The assembly search sequence is documented here:
http://msdn.microsoft.com/en-us/library/aa374224(VS.85).aspx

Page view tracker