SolidWorks API: Add-in, Stand-alone or Hybrid

01Executive summary

The choice between an add-in and a stand-alone client is often made by habit or by whichever example was to hand. It deserves better, because it determines the API surface available to you, whether you can react to what the user does, how long your build-and-test cycle takes, and how much installer engineering you will be funding.

Two requirements force an add-in: needing notifications, and needing the small set of API members that only work in-process. Absent both, the stand-alone model is materially cheaper to build, debug and ship — and a hybrid lets you take the add-in only where it is actually required.

02Definitions before comparison

The distinction is not the file extension and it is not whether a toolbar appears. An add-in is a class that implements the add-in interface, handles both lifecycle members, and is registered with COM and discoverable by SolidWorks. Everything else — including a library that drives SolidWorks, and an executable that looks thoroughly integrated — is a stand-alone by definition.

What actually differs
Dimension	Add-in	Stand-alone
Loaded by	SolidWorks	The user or the operating system
Process	In-process, same thread as the host	Separate process
Artefact	Registered class library	Executable
API reach	Complete, including in-process members	Complete except in-process members
Notifications	Available	Not available
Runs without SolidWorks open	No	Yes
Installation	Registration required	Copy and run

03The trade-offs, stated plainly

Add-in — for

Speed, reach and integration

Calls do not cross a process boundary, the whole API is reachable, notifications are available, and the product appears in the host's own menus from the moment SolidWorks opens.

Add-in — against

Cycle time and distribution

Every change requires closing SolidWorks — on every machine running the add-in. Registration means an installer or a documented manual procedure, and the COM and callback machinery obscures otherwise simple work.

Stand-alone — for

Simplicity and iteration

Connecting to SolidWorks is close to a single line. Debugging does not require closing the host, distribution can be as simple as copying files, and non-SolidWorks parts of the application can be developed without opening SolidWorks at all.

Stand-alone — against

Overheads and blind spots

Out-of-process calls carry marshalling cost, the in-process API members are unavailable, there is no notification channel, and the product is not integrated into the host's interface.

04A decision sequence

Answer in order and stop at the first yes.

Question 01Do you need notifications?
React to a save, a document change, a selection, a page event? Only an add-in can receive them. Stop here — the decision is made.
Question 02Do you need in-process-only API members?
A small set, including document preview and preview-bitmap operations, only function in-process. If your requirement touches them, it must be an add-in.
Question 03Must commands exist the moment SolidWorks opens?
If the product must be present in the host's menus at start-up, or must act on session start-up, that is an add-in.
Question 04Is call throughput genuinely critical?
Sustained calculation over an active model — mass property sweeps, large traversals, per-face queries — is where in-process execution earns its keep. Occasional automation is not.
Question 05None of the above?
Build the stand-alone. The savings in debugging, iteration and distribution are real and recurring, and you can migrate later far more easily than you can retrofit notifications.

The reversal cost is asymmetric

Turning a stand-alone into an add-in means adding an interface implementation, registration and a host-driven lifecycle around logic that already works. Discovering half way through an add-in that you did not need one costs nothing but the cycle time you already burned. The expensive mistake is choosing stand-alone when you needed notifications — which is exactly why the question is first.

05Hybrid architectures

The two models are not exclusive. The common hybrid keeps a thin add-in for the things only an add-in can do — menus, pages, notifications — and puts the substantive work in a separate component that can be developed and updated without closing the host.

Thin add-in shell
Implements the interface, registers, publishes commands and pages, and subscribes to the notifications the product needs.
Work component
A referenced library, a separate executable, or a COM object instantiated on demand. Holds the logic that changes most often.
Defined channel
Command-line arguments, a shared data store, registry values or another agreed mechanism carries context between the two.
Independent release
Because the shell changes rarely, most releases update only the work component — which shortens the cycle for the code that actually moves.

Choosing a channel between hybrid components
Channel	Suits	Watch for
Command-line arguments	One-shot invocations with small context	Length limits, quoting, and anything sensitive being visible in the process list
Shared data store	Structured or larger payloads, audit trails	Concurrency, locking, and cleaning up after an abnormal exit
Registry values	Small persistent settings	Privilege on machine-wide keys; unsuited to volatile data
Direct COM object	Rich, ongoing interaction	Lifetime and release discipline on both sides

06Summary matrix

Choose add-inNotifications, in-process members, start-up presence or sustained throughput. Accept the cycle-time and installer cost as the price of capability.

Choose hybridYou need some add-in capability, but the bulk of the logic is ordinary work. Thin shell, separate component, defined channel, independent release cadence.

Choose stand-aloneBatch processing, reporting, file preparation, migration, one-off automation. Cheapest to build, debug and distribute; migrate later only if a forcing requirement appears.

07Quick reference

Forcing requirements: Notifications and in-process-only API members. Either one settles the question.
Cycle-time cost: An add-in requires closing SolidWorks on every machine running it before it can be rebuilt or replaced.
Distribution cost: An add-in needs registration; a stand-alone can often be copied and run.
Performance: In-process avoids marshalling; the benefit is material only under sustained call volume.
Hybrid shape: Thin registered shell plus a separately released work component and a defined channel between them.

Add-in, Stand-alone or Hybrid Architecture