实现应用措施中的并行组件共享(二)
副标题#e#
当将现有组件修改为并行时，正是将它的激活方法改为利用相对路径和断绝全局状态。重要的是给它一个新的 CLSID、ProgId，而且重定名该文件，然后将这个 CLSID、ProgId 以及新文件名用于厥后的并行组件。这样做可以制止在并行版本上再注册该组件的非并行版本而引起的斗嘴。并行组件和他们以前的非并行版本不向后兼容。
状态存储
对付注册表中存储的状态（配置），需要将状态私有化为该应用措施运行的上下文。可以利用 GetModuleFileName() 函数配置一个虚拟根。应对 HKLM 和 HKCU 分支执行该操纵。
必需在每个版本的基本上完成注册配置，以得到注册表的断绝。注册表项是组件生存其状态的通用要领。因为在呆板中大概存在组件的差异版本，因此重要的是当从头编译时，能尽大概容易地找到您的表项的版本。得到一套优良的头文件和有用的 API，会使得这件工作变得简朴。
用下列定名约定在表项中存储注册状态：
HKCU\MyCompany\MyComponent\VersionXXXX\
譬喻，假定一个称为 EnableSuperCoolFeature 的设置配置有真或假的值。在注册表中存储该信息的传统方法为：
HKEY_CurrentUser\Software\MyCompany\MyComponent\
EnableSuperCoolFeature = TRUE
在并行共享环境下，该当用如下方法存储它：
HKEY_CurrentUser\Software\MyCompany\MyComponent\Version01.01
EnableSuperCoolFeature = TRUE
别的，假如确定需要断绝每个应用措施，可以利用
HKCU\MyCompany\MyComponent\VersionXXYY\SomeApplication\\
个中“SomeApplication”是 GetModuleFileName 的返回值。这样做使组件可以或许断绝它的配置，该配置只针对当前正在运行的应用措施。
抱负的环境下，应支持永久模子，以使应用措施担负起保持用户状态的责任而且不变动注册表。应用措施不必直接与组件的注册表项打仗。作为取代，组件应提供一些 API，以生存或规复与并行一致的配置。
对付全局状态下的交互，存储在除注册表以外的其他位置的配置，应以并行方法存储。这类存储包括：
被掩护的存储 (pstore)
WinInet 高速缓存
Microsoft SQL Server™ 或 Microsoft Jet 数据库
安装并行组件
安装之前
安装并行组件之前，必需确定在您的操纵系统中是否支持它们。下列代码检测并行共享是否可用。假如不行用，组件必需安装在系统目次中。
BOOL bPlatformSupportsSideBySide(void)
{
OSVERSIONINFOEX osviex ;
osviex.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);
// 若平台不支持 OSVERSIONINFOEX 布局，就不支持并行
// 在内核中，我们已经使这些修改连在一起
//
if (!GetVersionEx((OSVERSIONINFO *)&osviex))
{
return FALSE ; // 无 DLL 重定向
}
// 然而对付 NT，则 NT4 SP4 支持 OSVERSIONINFOEX 支持，但它不支持 DLL 重定向。
// 若 DLL 重定向呈此刻未来的 NT4 SP 中，必需更新此代码。
//
if ( (osviex.dwPlatformId == VER_PLATFORM_WIN32_NT) &&
(osviex.dwMajorVersion < 5) )
{
return FALSE ;
}
// 对付其他平台标识，假定具有并行支持
return TRUE ;
}
#p#副标题#e#
安装与卸载
正确安装和卸载组件很要害。抱负环境下，除了将组件复制到应用措施目次中或将其从应用措施目次中删除外，不该有其他的安装和卸装进程。可是，假如需要执行组件的 COM 注册或其他初始配置，则必需以与并行一致的方法执行。
Windows 2000 包括 Windows Installer 版本 1.1，它将支持并行组件的安装和卸载。（在 Windows 2000 宣布之后，Windows Installer 还可以联机利用。）当注册并行 COM 组件时，需要确认“类”表中的属性栏配置了 msidbClassAttributesRelativePath 位。这将用相对路径名注册组件，答允沟通组件的多个副本共存。
切记，当组件在应用措施目次中是私有的，一些其他应用措施大概在该呆板中安装了该组件的差异版本。当安装或卸载该组件时，您不但愿做有损于其他应用措施的事。因此利用您的组件的应用措施将靠您，通过自注册进口点 DLLRegisterServer 或 DLLUnregisterServer（对付 COM 组件）或 DllInstall（对付 Win32 或 COM 组件）来正确安装它。有关这些函数的具体信息，请参阅“平台 SDK”中的 “Register Server”（英文）。
要在应用措施目次中正确安装组件，请像安装通例组件一样执行下列步调：
注册 GUID 时，确认它们有相对路径名。
确认有对 GUID 的引用计数。
这有助于跟踪安装或卸装该 GUID 的次数。
假如 GUID 存在，则增加您的引用计数。
或
假如它不存在，则需要添加 GUID，并放入一个引用计数。譬喻：
{00000109-0000-0010-8000-00AA006D2EA4}
\InprocServer32
Default = "mycomponent.dll"
ReferenceCount=1
留意 范例库应包括在 DLL 中，而且不需要在系统注册表中注册。
要正确卸装应用措施目次中的组件， 请像安装通例组件一样执行下列步调：
递减引用计数。假如到达 0，则知道可以删除 GUID，因为没有其他用户。假如大于 0，暗示另一个应用措施安装在系统中并依赖于注册表的状态。
DLL/COM 重定向
#p#分页标题#e#
DLL/COM 重定向，要求在陈设应用措施时该应用措施是可执行的，而且所有的断绝组件安装在应用措施目次中，而不是系统目次中。别的，“.local”文件被陈设在应用措施目次中，以修改 Windows 绑定行为，使应用措施绑定到断绝组件，而不是全局共享版本。
于是，应用措施将利用能安详地并行运行同一组件的差异版本的组件，这些组件的差异版本安装在其他位置、另一个应用措施目次中或系统目次中。假如系统中的另一个应用措施要求差异的版本，您的应用措施将不受影响，而且两个应用措施将用它们各自的组件版本运行。
假如另一个应用措施在系统中安装了新的组件版本，该应用措施的组件版本将保持稳定，因为您已将它安装到您的应用措施目次中。在其他应用措施利用它的版本的同时，您的应用措施继承利用随该应用措施提供的组件版本。操纵系统可以同时加载这两个版本。
留意 必需用操纵系统正确注册断绝的 COM 组件，组件的每个版本才不会与该组件的其他大概存在的版本产生斗嘴。该注册要求，固然组件的实现可因版本而异，但诸如 CLSID、ProgID、范例库和线程模子等注册的 COM 元数据，不能因版本而异。
留意 Windows 2000 和 Windows 98 第二版本都支持 DLL/COM 重定向。在该版本以前的 Windows 操纵系统不支持他们。
利用 DLL/COM 重定向
DLL/COM 重定向答允开拓者或打点员有选择地将现有组件与正在成立和开拓的应用措施隔分开。本节接头如何激活 DLL/COM 重定向，以及如何选择要断绝的组件 。
激活 DLL/COM 重定向
通过“.local”文件的形式在逐个应用措施的基本上激活 DLL/COM 重定向。在与应用措施的 .exe 文件沟通的目次中，“.local”是一个空文件，它与应用措施的 .exe 文件名称沟通，而且在该名称的末了带有“.local”。
譬喻，要为称为“myapp.exe”的应用措施激活 DLL/COM 重定向，可在安装 myapp.exe 的沟通目次中建设一个称为“myapp.exe.local”的空文件。
一旦激活 DLL/COM 重定向，则每当应用措施装入一个 DLL 或 OCX 时，Windows 将首先在安装该应用措施的 .exe 文件的目次中查找该 DLL 或 OCX。假如在安装 应用措施的 .exe 文件的目次中找到该 DLL 或 OCX 的一个版本，则不管在应用措施或注册表中指定了什么目次路径，应用措施都将利用它。假如在安装应用措施的 .exe 文件的目次中未发明该 DLL 或 OCX 的版本，则利用一般搜索路径或处事器路径。
选择要断绝的组件
DLL/COM 重定向答允断绝现有组件，个中安装在计较机中的应用措施需要沟通组件的差异版本。不需要对该组件举办任何代码变动，因为一旦激活，DLL/COM 重定向将变动 Windows 绑定行为。
可是到今朝为止，并行执行组件的差异版本凡是已不是设计所思量的问题。当组件可以很容易地并行安装（安装在一个共享的位置而且与一个或多个应用措施断绝）时，它们大概不并行运行。假定任何时刻在计较机中只有一个组件版本，呈现这种环境是因为一些组件利用全局状态（如存储在注册表中的配置）。别的，当该组件定位它所需要的其他资源时，该组件大概会假设它所安装的特定目次。
由于这个原因，必需测试应用措施，该应用措施利用了安装在本身身上和其他应用措施情况中的断绝组件，该组件是断绝的。Microsoft 的履历表白在大大都方案中，共享的组件凡是是可以并行运行的，但在某些环境下，大概需要封锁一个应用措施，然后才气运行下一个应用措施。
选择要断绝的组件时应遵照下列指南：
不要实验断绝受“系统文件掩护”（随 Windows 2000 提供）所掩护的文件，包罗大部门 .sys、.dll、.exe 以及 .ocx 文件。
必需测试所有应用措施以确保并行的有效性，尤其在大概呈现共享的区域中，因为没有任何由当前操纵系统强制的并行。
当心失去对组件举办快速批改的本领，因为它们此刻在擅自定位的应用措施目次中。作为打点员，您需要知道需要批改组件的所有位置。
方案 I：将 ActiveX Controls 专门用于应用措施
#p#分页标题#e#
在该方案中，打点员无法开拓新的应用措施，因为新的应用措施利用在 Visual Basic 中创作的 ActiveX 控件的版本。该版本差异于当前开拓的应用措施所需要的版本。
这时，对付 ActiveX 控件的错误批改和其他修改引入了语义的不同。如，应用措施利用了一个有问题的控件版本，该控件版本没有颠末测试。打点员必需有本领运行差异版本的 ActiveX 控件，这些差异版本的 ActiveX 控件用于差异的应用措施，制止批改并从头测试大概受 ActiveX 控件变动影响的每个应用措施。
留意 在 Visual Basic 中，当前没有可供开拓人员编写内涵并行的 ActiveX 控件的便利途径。这是因为用 Visual Basic 创作的 ActiveX 控件在注册时将把 OCX 文件的全限定路径写入注册表中。
打点员可以或许强制新应用措施利用正确版本的 ActiveX 控件，而且通过将新应用措施的配置修改为下列值，以确认现有应用措施的设置没有变动：
在应用措施的 .exe 文件地址的目次中安装 ActiveX 控件的新版本。
在应用措施的 .exe 文件地址的目次中，安装一个 .local 文件，以指定每当运行该应用措施时都应从应用措施的 .exe 文件地址目次中装入 ActiveX 控件。
方案 II：将 Win32 DLL 专门用于一个应用措施
在该方案中，打点员得知在开拓了新的应用措施之后，一个现有的应用措施遏制事情。打点员可以或许诊断出问题是由于对共享组件举办修改引起的，这样做会导致共享组件的新版本不支持对先前版本的向后兼容。
打点员可以或许通过执行下列步调批改应用措施：
将共享 DLL 的先前版本安装到现有应用措施的 .exe 文件地址的目次中。
在现有应用措施的 .exe 文件的地址目次中建设一个 .local 文件。该 .local 文件指定当应用措施运行时，在应用措施的 .exe 文件地址目次中找到的 DLL 应从这里装入。
安装断绝的 COM Server 的留意事项
DLL/COM 重定向是通过在新的位置安装 DLL 或 OCX 文件（专用于应用措施）来实现的，可是将不断绝与 COM Server 关联的其他系统状态，这对付断绝 COM Server 具有一些特定寄义。
安装断绝的 COM Server 时，该当小心，以确保假如在计较机中已安装了组件的任何版本（譬喻通过其他应用措施），InprocServer 文件的位置不被断绝组件的新位置所包围。对付断绝的 COM Server，在运行时忽略 InprocServer 文件位置。可是不利用 DLL/COM 重定向的现有应用措施要求 InprocServer 文件位置继承指定先前安装的 COM Server 的位置。这意味着：
安装断绝的 COM Server 时，假如已在计较机中安装任何版本的 COM Server，请不要在安装时注册断绝的 COM Server。
相反，如坚断交的 COM Server 的版本尚未安装在计较机中，则必需注册它。这种问题呈此刻当 COM Server 与应用措施断绝、被安装在应用措施的 .exe 目次下，然后又安装了一个需要该组件的非断绝的应用措施。在这种环境下，卸载断绝的应用措施不行能将断绝的 COM 组件视为共享文件，因此卸载将间断其他应用措施。这意味着：
当安装断绝的 COM Server 时，假如在计较机中未安装 COM Server 的任何版本，则将 DLL 或 OCX 文件复制到应用措施的 .exe 目次和系统目次（或一些其他共享位置）中，而且在系统目次（或其他共享位置）中注册副本。
对付现有组件,一些版本大概由一些应用措施共享，而另一些版本大概专门用于一些其他的应用措施，较量公道的履历做法是：在安装利用潜在共享组件的断绝版本的应用措施之后，确保安装了该组件的共享版本和断绝版本，而且注册了共享版本。这样做答允卸载措施删除断绝版本，而不必担忧会间断其他应用措施
