If you’re building SolidWorks automation or evaluating how existing tools work, the architectural question of in-process versus standalone matters more than most developers initially expect. The choice affects which API calls you can make, how reliably the automation runs, and how much maintenance you’ll do when SolidWorks updates.

This is worth understanding whether you’re writing your own add-in or evaluating third-party tools.

The Two Execution Models

In-process automation runs inside the SolidWorks process. An add-in is a DLL loaded by SolidWorks at startup. When your add-in code runs, it’s in the same memory space as SolidWorks itself. You communicate with the SolidWorks API through a direct object reference — no inter-process communication, no marshaling.

Standalone automation runs in a separate process — a console application, a Windows application, or a script runtime. It connects to SolidWorks through COM automation, acquiring a reference to the running SolidWorks application via GetActiveObject("SldWorks.Application") or by launching a new instance programmatically. API calls cross the process boundary via COM marshaling.

Both approaches use the same SolidWorks API surface. But the implications of each are significant.

Feature Access and Reliability

The in-process add-in has full access to everything SolidWorks exposes, including APIs that are documented as requiring an active SolidWorks session. More importantly, in-process code runs synchronously in the SolidWorks message loop — which is how SolidWorks expects extensions to work.

Standalone automation introduces timing and threading issues that don’t exist in-process. When you call an API method from an external process, you’re making a cross-process COM call. SolidWorks has to marshal that call into its own thread. This works for many operations, but becomes unreliable for:

  • UI-dependent operations. Anything that triggers SolidWorks dialogs or requires user interface interaction becomes unpredictable from standalone context.
  • Event handling. SolidWorks fires events (document open, rebuild complete, etc.) inside its own process. Standalone code can subscribe to some events, but the mechanism is less reliable than in-process event handlers.
  • Sheet metal flat patterns. Accessing and exporting flat patterns requires operations that are most reliable when executed in-process. Standalone code can do it, but edge cases around feature resolution and configuration activation are more common.
  • Complex assemblies. Large assemblies with many configurations may not resolve correctly when driven from standalone automation, particularly if the correct top-level assembly context isn’t established.

For VBA macros — which are technically in-process because they run inside SolidWorks’s built-in VBA environment — most of these issues don’t apply. But macros have their own limitations: they can’t create proper UI, they can’t be deployed as persistent add-ins, and they run blocking the SolidWorks UI for the duration.

The Standalone Case

Standalone automation makes sense when:

  • You need to process files without a SolidWorks user present (batch processing on a server)
  • You’re integrating SolidWorks with an external system and the trigger comes from outside (a PLM system, an ERP event)
  • You need to run multiple SolidWorks sessions in parallel (though licensing restricts this)

The tradeoff is that you’re relying on SolidWorks’s COM server behavior, which is less tested and less documented than the in-process API path. Certain API calls simply don’t work reliably in standalone context. The SolidWorks API documentation notes some of these, but not consistently — you often discover the limitations through testing.

Version compatibility is also more fragile in standalone mode. The COM ProgID (SldWorks.Application) is version-independent in principle, but the actual behavior of specific API methods can differ between versions in ways that only manifest under cross-process COM calls.

Why In-Process Add-Ins Stay Stable

An in-process add-in is registered with SolidWorks as a proper extension. SolidWorks loads it at startup, calls its ConnectToSW entry point, and the add-in gets a SldWorks application reference directly — no COM marshaling, no timing dependency on when the SolidWorks process is ready to receive external calls.

This means:

  • API calls execute with the same reliability as SolidWorks’s own internal operations
  • Event handlers fire correctly and in the right context
  • UI elements (CommandManager buttons, menus, task panes) integrate properly
  • The add-in is available every time SolidWorks is open, without manual invocation

For automation that engineers use daily — batch export, BOM processing, file naming — the in-process add-in model is the right architecture. The user opens SolidWorks, the add-in is there, they use it. No separate process to launch, no COM connection to establish, no timing window to worry about.

CadShift is built as an in-process add-in for exactly this reason. Accessing flat pattern geometry, reading custom properties across an entire assembly, and driving batch export operations reliably requires the full in-process API access. The features that make it useful — bend line trimming, metadata embedding from custom properties, BOM-driven quantity tracking — depend on APIs that are most stable in-process.

What This Means for Evaluating Tools

When evaluating SolidWorks automation tools — whether commercial add-ins or internal development projects — ask:

Is this an in-process add-in or a standalone application?

If it’s standalone, understand what it can and can’t do. Standalone tools can be useful for specific cases, but they’re more fragile for complex sheet metal and assembly operations.

How does it handle SolidWorks version updates?

In-process add-ins need to be tested against each SolidWorks version, but the API surface is stable for core operations. Standalone tools may need additional work because COM marshaling behavior can change. A good add-in vendor will certify compatibility with current versions as part of their release cycle.

What happens when SolidWorks rebuilds or resolves configurations?

This is the stress test for automation reliability. An in-process add-in can handle rebuild events and wait for resolution to complete before proceeding. Standalone code has to poll or use external synchronization mechanisms that are inherently less reliable.

The VBA Macro Hybrid

Worth noting: VBA macros run in SolidWorks’s built-in VBA environment, which is in-process. This is why macros have access to most of the API surface and generally work for prototyping. The limitation isn’t access — it’s that macros are hard to deploy, maintain, and extend into real applications.

The practical path for most teams is: start with a macro to validate the automation logic, then either productionize it as a proper add-in or find an existing add-in that covers the use case. Leaving critical automation running as a VBA macro in production is the pattern that accumulates technical debt fastest — as covered in the discussion of four levels of CAD automation.

Choosing the Right Approach

For one-off integrations where SolidWorks is a data source and the logic lives elsewhere, standalone automation via COM is workable. Batch-processing files on a server overnight, triggering an export from a PLM workflow, extracting data for reporting — these are reasonable standalone use cases.

For daily workflow tools that engineers use repeatedly, in-process add-ins are the right architecture. The reliability difference is meaningful at scale, and the user experience of having the tool always present in SolidWorks is significantly better than requiring engineers to launch a separate application.

Understanding this distinction helps explain why the best SolidWorks automation tools are add-ins, not scripts — and why the API-level access they provide is genuinely different from what macros and standalone tools can deliver reliably.