64位应用程序的COM注册

本文关键字：注册 COM 应用程序 64位 | 更新日期: 2024-09-22 05:33:37

我正在为使用第三方SDK的64位应用程序创建安装程序。这个SDK需要COM注册，并且似乎有一些相互冲突的指令，所以我想找出以下方面的最佳实践：

为了实现无注册表激活（对于支持它们的COM DLL），我只需将它们放在同样包含Interop包装器的应用程序文件夹中。不管怎么说，他们的指示就是这么说的。

要使用剩余的COM DLL，它们有以下说明：

LEADTOOLS Multimedia for.NET现在支持LEADTOOLSMultimedia COM对象的无注册表激活（请注意，所有其他LEADTOOL DirectShow筛选器和编解码器仍然需要使用regsvr32注册）。重新分发所需的新文件包括：ltmm.manifest和ltmm19.dll（32位）或ltmm19x.dll（64位）（取决于应用程序的处理器体系结构）。为了让您的应用程序使用无注册表激活，请将文件安装到与Leadtools.Multmedia.dll相同的文件夹中。

该工具包还为DSKernel2.dll（32位）和DSKernel2x.dll（64位）COM对象提供了可选的清单文件，以简化部署（几乎所有应用程序都需要DSKernel dll。可以选择性重新分发的新文件包括：DSKernel2.清单（32位的）或DSKernel2x.manifest（64位的）（取决于应用程序的处理器体系结构）。将这些文件安装到与DSKernel2.dll/DSKernel2x.dll相同的文件夹中，以便您的应用程序使用无注册表激活。

***建议将x64运行时安装在windir''SYSWOW64文件夹中，而不是windir''System32文件夹中，因为某些开发环境（如VS8）不会导入放置在windir'' System32文件夹中的引用，因为该文件夹是32位应用程序。

因此，即使你忽略了上面的上下文，我的问题仍然存在：

regsvr32有两个版本，一个在Windows'System32文件夹中，另一个在Windows'SysWOW64文件夹中。哪一个用于注册纯64位dll？

此外，在枚举系统、文件夹时，SpecialFolder枚举的以下值似乎与直觉相悖，MSDN对它们的描述并没有透露太多信息。

Environment.SpecialFolder.System > Maps to Windows'System32
Environment.SpecialFolder.SystemX86 > Maps to Windows'SysWOW64

如有任何指导，我们将不胜感激。请注意，使用这些文件的应用程序的目标是x64，而不是AnyCPU，并且支持的最低操作系统必须是Windows 7。

64位应用程序的COM注册

关于LEADTOOLS多媒体，尤其是在构建.NET应用程序时，有两种类型的DLL：

  • 核心工具包DLL，即DirectShow的Leadtools.Multimedia.DLL和Media Foundation的Leadtools.mediation.DLL。这些核心DLL包含主控件（捕获、转换和播放）以及其他几个辅助对象，它们不需要注册（使用RegSvr32）。这些是我们本机COM库的.NET包装器/互操作（到LTMM###.dll）。请注意，DirectShow&MediaFoundation是用COM实现的。因此，LEADTOOLS还创建了COM DLL。由于.NET本身不能与COM一起工作，我们创建了这些包装器，以便使用我们的工具更容易地编写.NET应用程序。如果愿意，可以将这些注册到全局程序集缓存（GAC）中，但这不是必需的。

  • 附加的编解码器和滤波器，例如H.264和H.265。每个（COM）编解码器或过滤器通常都有自己的DLL，并且需要使用RegSvr32进行注册。对于这些编解码器和筛选器的64位和32位版本，我们建议您将这些DLL部署到SysWOW64文件夹，并从SysWOW六十四文件夹向RegSvr32.exe注册。

如果要使用另一个具有免注册COM的组件，则必须引用刚刚放置在应用程序文件夹中的程序集。简单地将它们放在那里是必要的，但还不够，因此您需要更改应用程序的清单，或者创建一个依赖于隔离组件的清单。

例如：

<assembly manifestVersion="1.0"
          xmlns="urn:schemas-microsoft-com:asm.v1">
  <assemblyIdentity type="win32"
                    name="MyApplication"
                    processorArchitecture="amd64"
                    version="1.0.0.0" />
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!-- Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />
      <!-- Windows 8 -->
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />
      <!-- Windows 8.1 -->
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />
    </application>
  </compatibility>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity … />
    </dependentAssembly>
  </dependency>
</assembly>

将依赖程序集的标识（在…中）替换为隔离COM组件为目标体系结构标识自己的标识。

您的问题的其余部分似乎是针对开发机器的环境提出的。

对于64位Windows中的64位DLL，可以在C:''Windows''System32中进行部署。

对于64位Windows中的32位DLL，可以在C:''Windows''SysWOW64中进行部署。

这可能没有多大意义，但这就是我们所拥有的。这样，您就不必更改所有VS项目或nmake文件以具有两组库引用，例如，根据目标系统的不同，您总是使用user32而不是user32和user64。事后看来，在大约20年前，在库名称中添加架构比特可能是一个错误。

相关文章：