Reg-free COM allows using a copy-deployment for applications depending on COM/ActiveX component. As the name implies, Reg-free COM means there's no need to register COM/ActiveX components prior to using them. To achieve this, the application requires one or more manifest files which describe the used COM/ActiveX components. The Windows operating system will then ensure the required COM/ActiveX components are available when it starts your application. Consequently, there is no longer any need to install/register COM/ActiveX components required by an Xbase++ application programatically or via an installer. The following section outlines the procedure for creating the required manifest files.

Procedure:​

1. Add a <dependency> section to your application's manifest file for the COM/ActiveX components to be loaded during startup. In the example below, the COM/ActiveX components are located in the sub-directory "activex". This is similar to the way the manifest is already used in Xbase++ apps for requesting a certain version of the Common Controls DLL for enabling visual style-support.

myapp.exe.manifest
XML: 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
   <assemblyIdentity
      type="win32"
      name="myapp.exe"
      version="1.0.0.0"/>

    <!-- Section for announcing application's dependency to COM/ActiveX components
    in sub-folder "activex" -->
    <dependency>
       <dependentAssembly>
          <assemblyIdentity
             type="win32"
             name="activex"
             version="1.0.0.0" />
       </dependentAssembly>
    </dependency>

    <!-- Request version 6.0 of the Common Controls DLL for enabling visual styles -->
    <dependency>
       <dependentAssembly>
          <assemblyIdentity
             type="win32"
             name="Microsoft.Windows.Common-Controls"
             version="6.0.0.0"               
             processorArchitecture="X86"
             publicKeyToken="6595b64144ccf1df"
             language="*"/> 
       </dependentAssembly>
    </dependency>
</assembly>


2. Add a so-called component manifest file describing the COM/ActiveX components in the "activex" sub-directory. This component manifest file contains information about the binaries as well as about the COM/ActiveX classes which must be registered during application start-up.

activex.manifest
XML: 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
       type="win32"
       name="activex"
       version="1.0.0.0" />
   <file name="mscomct2.ocx">
      <comClass
          description="Microsoft Animation Control 6.0 (SP6)"
          clsid="{B09DE715-87C1-11D1-8BE3-0000F8754DA1}"
          threadingModel="Apartment"
          progid="MSComCtl2.Animation"
          tlbid="{86CF1D34-0C5F-11D2-A9FC-0000F8754DA1}" />
      <comClass
          description="Animation General Property Page Object"
          clsid="{586A6352-87C8-11D1-8BE3-0000F8754DA1}" />
      (...)
   </file>

   <file name="mscomctl.ocx">
      <comClass
          description="Microsoft ListView Control 6.0 (SP6)"
          clsid="{BDD1F04B-858B-11D1-B16A-00C0F0283628}"
          threadingModel="Apartment"
          progid="MSComctlLib.ListViewCtrl"
           tlbid="{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}" />
      (...)
   </file>
</assemblyIdentity>

  • The <assemblyIdentity> name must exactly match the <assemblyIdentity> name requested in the application manifest (in this example: "activex").
  • The filename of the component manifest file must exactly match the <assemblyIdentity> name plus the extension ".manifest" (in this example: "activex.manifest").
  • The component manifest file and the required COM/ActiveX components must be placed in a sub-directory with the same name as the <assemblyIdentity>.
  • If the version of a COM/ActiveX component changes, or if different components are required, the manifest file describing the dependent binaries needs to be generated again.
Click to expand...

If one of the rules above are violated, the operating system loader will not find the component manifest file.

Technical Background​

For specifying its dependencies on certain binaries, an application lists these so-called dependent assemblies in a <dependency> section of its manifest file, optionally with the required file version, language flavor and other information.
Each of these dependent binaries can also have an associated manifest file, giving additional information and listing dependencies. For Reg-free COM, this includes information not only about ActiveX binaries, but also about the COM classes which should be registered by the OS when the application is loaded.
Several tools are available for generating a proper manifest file for the COM/ActiveX components being used by an application. These retrieve the required information from the components installed on the development machine.
  1. MT.EXE - Included in the Windows SDK
    mt.exe -tlb:activexcomponent.ocx -dll:activexcomponent.ocx -out:activexreg.manifest
  2. REGSVR42.EXE - CodeProject project
    regsvr42 -client:myapp.exe activexcomponent.ocx
    -or-
    regsvr42 -client:myapp.exe -dir:directory_with_ocx_files
    https://www.codeproject.com/Articles/28682/regsvr42-Generate-SxS-Manifest-Files-from-Native-D

Debugging manifest file issues​

Windows writes information about problems in your application's manifest file to "application" section in the system event log. In addition, the sxstrace.exe tool can be used for debugging manifest file issues as follows:
  1. Run sxstrace in a separate command shell prompt like this:
    sxstrace Trace -logfile:tmp.log
  2. Start your application
  3. End tracing by pressing ENTER in the command shell prompt
  4. Run sxstrace like this:
    sxstrace Parse -logfile:tmp.log -outfile:analyzed.txt
This creates a text file named analyzed.txt with the information gathered by sxstrace.

External manifest files, i.e. manifests which are deployed alongside the .EXE file, are cached by the system. This can lead to the situation where changes applied to a manifest file during development have no effect. To work around this problem, either rebuild your .EXE file or copy all files to a new folder. Both will prompt the operating system to re-read your executable's manifest file.
Click to expand...

An example with manifest files suitable for deploying the ActiveX components shipped with the Xbase++ development package can be downloaded from here.