combridge
COM-automation host for Windows desktop apps, with a plugin model.
- Commits
- 19
- Stars
- 1
- Created
- May 24, 2026
A single CLI that drives Windows desktop applications over COM through a plugin architecture. One host executable, one plugin per application — SolidWorks, Excel, Word, PowerPoint and Outlook ship in the box.
Drop a plugin DLL into plugins/<name>/ and the host gives you multi-instance session management, a C# script-hosting environment (.csx files with plugin interop assemblies pre-referenced), and a session picker that defaults to the most-recently-focused window. One exe, many apps.
Shipped with plugins for SolidWorks (CAD automation), Excel (spreadsheet manipulation), Word (document editing), PowerPoint (presentation control), and Outlook (email automation). Each plugin exposes its own commands (solidworks active-doc, excel dump-sheet) while all share the same session-picking and script-hosting infrastructure.
Why the plugin model matters
The alternative is one exe per app. Each exe carries the full host, discovery logic, session management, and script runtime—duplicated five times over. Combridge replaces that with one exe per machine. The plugins are thin: they define commands, set up interop assemblies, and tell the host how to find app instances. The host handles the rest—attachment, session picking, script compilation, lifecycle.
One exe + five plugins = one deployment. Easier to test a plugin in isolation. Easier to add a new app (just author a new plugin). Easier to maintain when COM quirks surface.
Session picking
By default, combridge attaches to the most-recently-used session—the window the user was just looking at. Explicit session selection is available (--session 2, --session "MyFile.xlsx", --session pid:23456) but most of the time you don’t need it. The CLI just works.
Script hosting
.csx files (Roslyn C# scripts) run with plugin interop assemblies pre-referenced and globals injected (swApp, swDoc for SolidWorks; wb, ws for Excel). Write a few lines of C# and the host compiles and runs it in-process. No using statements, no manual COM object creation—just the logic.
19 commits, Windows-only, no test suite. Early and sharp in scope.
Where this stands
Better at
- Unified CLI for multiple Windows desktop apps with one host executable and many plugins, replacing the one-exe-per-app pattern.
- Multi-instance session manager with MRU (most-recently-used) selection by default; users don't need to specify which window they're targeting.
- C# script hosting (`.csx` files) with plugin interop assemblies pre-referenced, enabling in-process automation without manual COM setup.
- Plugin architecture: drop a DLL into `plugins/<name>/` and the host discovers it automatically, eliminating monolithic binary bloat.
Worse at
- No test suite; 19 commits and zero tests, so defensive coding against COM quirks is limited.
- Windows-only, via COM; there is no macOS, Linux, or other platform support.
- Limited to applications that expose COM interfaces; cannot automate applications that only offer other integration models.
Pick something else when…
- Office REST APIs (Excel, Teams, OneNote) or Graph APIYou're automating Microsoft cloud services; REST APIs often require less ceremony than COM and work cross-platform.
- UiPath Community or Power AutomateYou need broader platform coverage, extensive pre-built connectors, or a visual workflow designer.
- Direct COM calls or Windows Automation FrameworkYou only need to drive one application and prefer not to vendor an extra tooling layer.