Problems this service addresses
- You need to maintain an existing app that uses COM / ActiveX / OCX
- You are stuck on registry registration, RegAsm, regsvr32, or administrator permissions
- You need to decide how to connect 32-bit components to a 64-bit app
- You want to clean up the boundary between .NET and C++ into a maintainable shape
- You want to keep old components while making them usable from new apps
COM problems are rarely just code logic. They usually involve process bitness, registration targets, hosts, permissions, and threading models all at once.
Themes we handle well
- New development and repair of COM components
- Investigating ActiveX / OCX and sorting out registration and distribution
- Evaluating Reg-free COM
- Architecture design across the 32-bit / 64-bit boundary
- Wrapping existing assets with C++/CLI, COM bridges, or out-of-process isolation
Typical way of working
- First, we map out the host applications, target components, bitness, and registration state.
- Next, we decide whether to keep things in-proc, move them out of process, or replace them in stages.
- Implementation covers registration, distribution, permissions, logging, and rollback, in a form your team can reproduce on site.
When this is a good fit
- You have Windows assets involving COM / ActiveX and fewer people left who can maintain them
- A bitness change in Visual Studio or Office broke your existing components
- You want to use existing components from a new .NET app while preserving their behavior
- Before a full replacement, you want to sort out the boundary first and extend their life safely