ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
by John Loomes
Introduction
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 WinntSystem32 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. WINNTSYSTEM32, 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.
