What Reg-Free COM Is - How Registration-Free COM Works, and Where It Fits or Does Not

The short answer

• Reg-Free COM keeps COM registration data in a manifest (XML) instead of the registry
• At runtime, CoCreateInstance resolution looks at the activation context first
• This lets you keep COM DLLs and OCXs private to each application
• Main wins: easier XCOPY deployment, fewer version collisions, and uninstalls that do not damage other products
• However, the 32-bit / 64-bit problem does not disappear. Reg-Free COM does not solve that.

Why ordinary COM deployment hurts

A normal COM component registers the following in the registry:

• CLSID (the class identifier)
• ProgID (a friendlier name for humans)
• InprocServer32 (the path of the DLL to load)
• ThreadingModel (Apartment / Both)
• TypeLib (type information)

This global registration model is shared by everyone, and that shared culture tends to backfire:

• One product’s installer overwrites another product’s COM registration
• An uninstaller damages a COM component that other products still need
• It works on the developer machine but fails on production
• 32-bit and 64-bit registrations drift apart in subtle, eerie ways

Reg-Free COM is a way to reduce that deployment-model pain.

How it works

1. Application manifest

The application side declares which side-by-side assemblies it depends on.

MyApp.exe.manifest (placed next to the EXE, or embedded as a resource):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity type="win32" name="KomuraSoft.MyApp"
    version="1.0.0.0" processorArchitecture="amd64" />
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32"
        name="Vendor.CameraControl.Asm"
        version="1.0.0.0" processorArchitecture="amd64" />
    </dependentAssembly>
  </dependency>
</assembly>

2. Component manifest

The COM side carries the information that would normally live in the registry. Embedding it in the DLL as a resource is the least accident-prone option.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity type="win32"
    name="Vendor.CameraControl.Asm"
    version="1.0.0.0" processorArchitecture="amd64" />
  <file name="Vendor.CameraControl.dll">
    <comClass
      clsid="{01234567-89AB-CDEF-0123-456789ABCDEF}"
      progid="Vendor.CameraControl.1"
      threadingModel="Apartment" />
  </file>
</assembly>

3. Activation context

When the application calls CoCreateInstance, the COM runtime looks at the active activation context first. If the manifest holds the necessary information, the call resolves without touching the registry.

Note: if the manifest is missing something, resolution falls back to the usual registry-based path. On a developer machine, a leftover registry entry can quietly rescue you, which is exactly how subtle bugs hide.

What you actually get

1. XCOPY deployment becomes realistic - everything sits in the application folder
2. Version collisions are easier to avoid - each application can use its own version
3. Existing code barely changes - the CoCreateInstance side stays largely untouched
4. Removal and rollback are easier - swap the folder and you are done

Where it fits, and where it does not

Where it fits

| Situation | Fit | |——|——| | Shipping a COM DLL or OCX bundled with one application | Excellent | | Running multiple versions side by side on the same PC | Excellent | | Avoiding registration accidents from vendor components | Good | | Using ActiveX or OCX privately inside one app | Good | | Keeping deployment light without changing call sites | Good |

Where it does not fit, or needs caution

| Situation | Comment | |——|———| | You want COM shared machine-wide | Reg-Free COM brings little value | | Bitness does not match | Reg-Free COM does not solve this | | Heavy reliance on non-standard registration | Hard to express in a manifest | | Dependent DLL deployment is unmanaged | You will fail elsewhere instead | | Design-time tooling assumes the registry | You need a different operational design |

Common misconceptions

1. “Bitness problems disappear.” They do not. A 32-bit process can only load 32-bit DLLs.
2. “The registry is never consulted.” If the manifest is incomplete, resolution falls back to the registry.
3. “Type libraries are taken care of automatically.” Runtime activation is helped, but design-time references are a separate problem.
4. “Any ActiveX or OCX just works.” Components with heavy installer logic or licensing tend to push back.
5. “.NET Framework and .NET 8 are the same.” The toolchains differ. On .NET 5+, you use EnableComHosting and EnableRegFreeCom.

.NET Framework vs .NET 5+ vs .NET 8

Where people get stuck

1. Works on the developer machine, fails on the target - it was the leftover registry entry doing the work. Verify on a clean environment.
2. “side-by-side configuration is incorrect” on launch - chase it with the event log and sxstrace.
3. Manifest mismatch - name, version, and processorArchitecture must line up.
4. Forgotten dependent DLLs - Reg-Free COM reduces COM-registration pain, but it does not deal with native dependency resolution.
5. Putting the type library off until later - keep runtime activation and design-time references as two separate conversations.

How to validate

• Test on a clean environment (one with no COM registration)
• Use sxstrace to follow how the manifest is being resolved
• Get bitness and dependent DLLs straight first
• Treat runtime activation and design-time references as separate problems

Summary

Reg-Free COM is a way to pull COM activation back down to the application level.

Working principles:

1. Treat it as an activation story, nothing more
2. Separate runtime and design-time concerns
3. Verify on a clean environment
4. Get bitness and dependent DLLs straight first