COM registration for a 64-bit application

Question

I am creating an Installer for a 64-bit application that uses a third-party SDK. This SDK requires COM registration and seems to have some conflicting instructions so I'd like to find out best practices regarding the follows:

To achieve registry-free activation (for the COM DLLs which support them), I am simply placing them in the application folder that also contains the Interop wrappers. This is what their instructions say anyway.

To use the remaining COM DLLs, they have the following instructions:

LEADTOOLS Multimedia for .NET now supports registry-free activation for LEADTOOLS Multimedia COM objects (Note that all other LEADTOOLS DirectShow filters and codecs still need to be registered using regsvr32). New files required for redistribution include: ltmm.manifest and either ltmm19.dll (32-bit) or ltmm19x.dll (64-bit), (depending on the processor architecture of your application). In order for your application to use registry-free activation, install the files to the same folder as Leadtools.Multimedia.dll.

The toolkit also provides optional manifest files for the DSKernel2.dll (32-bit) and DSKernel2x.dll (64-bit) COM objects to simplify deployment (the DSKernel DLL will be required for almost all applications. New files that can optionally be redistributed include: DSKernel2.manifest (32-bit) or DSKernel2x.manifest (64-bit), (depending on the processor architecture of your application). Install these files to the same folder as DSKernel2.dll/DSKernel2x.dll in order for your application to use registry-free activation.

*** It is recommended that you install the x64 runtime in the windir\SYSWOW64 folder instead of the windir\System32 folder because some development environments (like VS8) will not import references that are placed in the windir\System32 folder since that is a 32-bit application.

So my question stands even if you ignore the above context:

There are two versions of regsvr32, one in the Windows\System32 folder and the other in the Windows\SysWOW64 folder. Which one to use for registering purely 64-bit dlls?

Furthermore, when enumerating system, folders, the following values for the SpecialFolder enumeration seem counter-intuitive and MSDN description for them does not reveal much.

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

Any guidance would be appreciated. Note that the application consuming these files targets x64, NOT AnyCPU and the minimum supported OS has to be Windows 7.

Answer 1

About LEADTOOLS Multimedia in particular, there are 2 types of DLLs when you're building a .NET application:

• The core toolkit DLL, which is Leadtools.Multimedia.dll for DirectShow and Leadtools.MediaFoundation.dll for Media Foundation. These core DLLs contain the main controls (capture, convert and playback) along with several other helper objects and they do not require registering (using RegSvr32). These are .NET wrappers/interops (to LTMM##.dll) for our native COM libraries. Note that both DirectShow & MediaFoundation are implemented with COM. For this reason, LEADTOOLS also created COM DLLs. Since .NET does not work with COM natively, we created these wrappers to make it easier to write .NET applications using our tools. You could register these into the Global Assembly Cache (GAC) if you wish, but it is not required.

• Additional codecs and filters such as H.264 and H.265. Each (COM) codec or filter usually has its own DLL and these require registering using RegSvr32. For both the 64-bit and 32-bit editions of these codecs and filters, we recommend you deployed these DLLs to the SysWOW64 folder and register them with the RegSvr32.exe from the SysWOW64 folder also.

Answer 2

If you want to use another component with registration-free COM, you must refer the assemblies you just placed in the application folder. Simply placing them there is necessary, but not enough, so you need to change your application's manifest, or create one, that depends on the isolated component.

For instance:

<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>

Replace the dependent assembly's identity (in …) with the one that the isolated COM component identifies itself for your target architecture.

The rest of your question seems to be oriented to the development machine's environment.

For 64-bit DLLs in a 64-bit Windows, you deploy in C:\Windows\System32.

For 32-bit DLLs in a 64-bit Windows, you deploy in C:\Windows\SysWOW64.

It may not make much sense, but that's what we have. This way, you don't have to change all your VS projects or nmake files to have two sets of library references, e.g. you always use user32 instead of user32 and user64 depending on the target system. In further hindsight, it might have been a mistake to add the architecture bitness to library names about 20 years ago.