Side-by-Side Component Sharing in Windows 2000

by John Loomes


Side-by-side component sharing and COM re-direction were introduced in Windows 2000, ME and 98 as a means of combating 'Dll Hell' situations where applications require different versions of the same COM component (a .DLL for example).

Side-by-side component sharing and COM re-direction were introduced in Windows 2000, ME and 98 as a means of combating 'Dll Hell' situations where applications require different versions of the same COM component (a .DLL for example). Historically, problems have arisen when non-backwardly compatible versions of COM components, and poorly written applications have lead to 'DLL Hell', the situation where two applications cannot co-exist as they require different version of the same component. With many COM components being shared amongst many applications this can become a huge integration problem. Microsoft have recently addressed this situation by providing two mechanisms to get around this problem - Side-by-side Component Sharing and COM redirection. This article discusses these mechanisms and explores the good (and bad) things they offer.

The Solutions

Microsoft provides two subtly different strategies for addressing these issues, as follows:

Side-by-side Components

When writing applications, Developers design components that support execution of multiple versions of the component. This allows individual applications to use a private version of a given component, thus isolating the component from any other applications, and therfore eliminating 'dll Hell'.

DLL/COM Redirection

An application is re-engineered such that existing components that the application requires are made private to the application - thus isolating them from any other versions of the same components on the machine and eliminating 'DLL Hell'

The two strategies sound almost the same at first glance but there are significant differences:

Side-by-Side components are written specifically such that several versions can be loaded at the same time. This is achieved by changing the COM registration code to allow access by a relative path. Redirection of components does not require any changes to internal code of COM objects, and as such may not work in every situation. Some existing applications and components will have been written in a such a way that that running two concurrent version will not be possible - they may be hardcoded to launch from Winnt\System32 for example. It is therefore crucial to test applications and components that have been modified with COM Redirection both in isolation and in conjunction with other application that are using other versions pof the redirection Component(s).

Whch Strategy To Use?

As a rule, when developing new applications that require resilience against Dll Hell problems, one would develop Side-By-Side components. When deploying existing applications in an environment where COM conflicts are causing problems, use COM Redirection.

Advice on Creating Side by Side Components and Using COM Redirection

  • Do not use either strategy with any files covered by Windows File Protection in Windows 2000. For more information on Windows File Protection, see my article HERE.

  • Test all components thoroughly. Both from the point of view of the Parent application. and also with any other applications using the same Components.

  • Beware that once you have isolated Components, you need to know exactly which version of a component goes with which appllication. This has implications when applying patches to components.

  • Components isolated using COM Redirection may not work if they use Global State, as they may make the assumption that there will be only one instance of the Component on a machine.

How to Use COM Redirection

COM redirection for existing application is acheived by moving the components to be isolated from the shared location e.g. WINNT\SYSTEM32, and placing them in the applications program directory. A zero byte length file is then created in the same directory with a suffix of .LOCAL and a prefix which is the name of the application .exe in question. When the application is executed, the O/S finds the .LOCAL file, and instructs from application to use COM components in the current directory, rather than in any other location on the machine.

Further Information

This article is merely an overview of these strategies. For more detail click HERE to be taken to Microsoft's MSDN page on this.

This article was originally published on Dec 4, 2000
Page 1 of 1

Thanks for your registration, follow us on our social networks to keep up-to-date