KEVOS
ArticlesServicesCase studiesAboutContact
ArticlesServicesCase studiesAboutContact
← ArticlesSolidWorks API: Add-in, Stand-alone or HybridEngineering · Computing & SoftwareLesson 7/10← PrevNext →
GuidePublished 4 Aug 2026Updated 13 Aug 202610 min readBy Kevin JoginSolidWorks APIsoftware architecturedecision frameworkCAD automation
On this page

Ask about this page

KEVOS AISolidWorks API: Add-in, Stand-alone or Hybrid

KEVOS knowledge first · trusted web sources when needed

KEVOS® Knowledge Library · SolidWorks API Add-in Development

Add-in, Stand-alone or Hybrid Architecture

A decision framework for the choice that shapes everything downstream — what each model can do, what each costs to build and ship, and when a hybrid is the honest answer.

  • Doc № KL-ENG-COMP-007
  • Engineering › Computers
  • Part 07 of 10
  • 11 min read
  • Updated 2026-08-04

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
DimensionAdd-inStand-alone
Loaded bySolidWorksThe user or the operating system
ProcessIn-process, same thread as the hostSeparate process
ArtefactRegistered class libraryExecutable
API reachComplete, including in-process membersComplete except in-process members
NotificationsAvailableNot available
Runs without SolidWorks openNoYes
InstallationRegistration requiredCopy 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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  1. Thin add-in shell

    Implements the interface, registers, publishes commands and pages, and subscribes to the notifications the product needs.

  2. Work component

    A referenced library, a separate executable, or a COM object instantiated on demand. Holds the logic that changes most often.

  3. Defined channel

    Command-line arguments, a shared data store, registry values or another agreed mechanism carries context between the two.

  4. 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
ChannelSuitsWatch for
Command-line argumentsOne-shot invocations with small contextLength limits, quoting, and anything sensitive being visible in the process list
Shared data storeStructured or larger payloads, audit trailsConcurrency, locking, and cleaning up after an abnormal exit
Registry valuesSmall persistent settingsPrivilege on machine-wide keys; unsuited to volatile data
Direct COM objectRich, ongoing interactionLifetime 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.

08Where this leads

Key takeaways

  1. Decide deliberately and record why. This choice constrains the API surface, the release process and the support burden.
  2. Two requirements force an add-in — notifications and in-process-only members. Ask about them before anything else.
  3. Absent a forcing requirement, the stand-alone model is cheaper across the whole lifecycle, not just at the start.
  4. A hybrid buys most of the capability for a fraction of the cycle-time cost by keeping the registered shell thin.
  5. Migrating a stand-alone into an add-in is straightforward; retrofitting notifications into an architecture that cannot receive them is not.

Continue in this pathway

  • Part 01Add-in architecture and the integration model
  • Part 02Development environment and project configuration
  • Part 03COM registration and add-in discovery
  • Part 04Command Manager, menus and toolbars
  • Part 05Property Manager Pages and the control model
  • Part 06Event and notification architecture
  • Part 07Add-in, stand-alone or hybrid
  • Part 08Planning, structure and debugging discipline
  • Part 09Deployment methods and installer engineering
  • Part 10Licensing, distribution and commercialisation

KEVOS® — Precision to Vision. Prepared by Kevin Jogin for the KEVOS® Knowledge Library. Interface names, enumerators and registry paths refer to the SolidWorks® API as published by Dassault Systèmes SolidWorks Corporation; SolidWorks® is their registered trademark. Code listings are original KEVOS® illustrations written to demonstrate the pattern under discussion and are supplied without warranty.

Handbook application: from concept to controlled practice

Purpose. This expanded section turns the original page into a practical handbook. It preserves the supplied material and adds a repeatable way to apply, check and review SolidWorks API: Add-in, Stand-alone or Hybrid. It does not replace a contract, legislation, a controlled standard, competent engineering judgement or specialist advice.

The operating aim is to carry the subject from function and assumptions through design evidence, verification and controlled release. Read the original explanation first, then use the workflow and checks below to convert knowledge into evidence.

Apply SolidWorks API: Add-in, Stand-alone or Hybrid by beginning with the duty, not the component or software command. Convert the key ideas—solidworks, hybrid, decision, add-in, stand-alone—into measurable requirements and interfaces. Record operating and non-operating environments, duty cycle, expected life, loads, energy sources, human interaction and reasonably foreseeable abnormal conditions. When a value is not a project requirement or verified supplier datum, identify it as an assumption or illustrative value.

Create a calculation and evidence trail that another competent person can audit. Every input should carry a source, unit, revision and uncertainty or tolerance where relevant. Every model should state its boundary conditions and limitations. Keep nominal capacity separate from design capacity, and keep verification margin separate from an arbitrary safety factor. If a code or standard governs the work, confirm the applicable edition and contractual status rather than copying a number from a secondary summary.

Design for manufacture, assembly, inspection, operation and maintenance at the same time. A technically valid geometry can still fail because it cannot be fixtured, measured, cleaned, guarded, reached or replaced. Review process capability, datum or reference strategy, tolerance accumulation, access, error-proofing and changeover. Where people interact with plant, apply the hierarchy of controls and consult those who will operate, clean, maintain and recover the equipment.

Plan verification before release. Define the characteristic, method, equipment, sample or test condition, acceptance criterion, record and responsible person. Validation then asks a different question: whether the resulting system is effective and suitable in the intended use context. A passed drawing check or analysis does not by itself validate usability, maintainability or production performance.

Step-by-step operating method

  1. Define the duty. Capture the required function, interfaces, operating environment, life, loads and unacceptable outcomes.
  2. Establish the model. Identify governing principles, units, material or process data, assumptions and uncertainty.
  3. Develop alternatives. Compare feasible concepts against performance, manufacturability, safety, maintainability and cost.
  4. Verify the design. Use analysis, test, inspection or demonstration with acceptance criteria defined before execution.
  5. Release and learn. Baseline the design, control changes, retain evidence and feed operating results into the next revision.

Illustrative design review record

Illustrative values only. Build a one-page record with the required function, input sources, assumptions, governing load or process condition, failure consequences, selected concept, verification method and acceptance criterion. Mark every numerical input as project requirement, verified supplier data, measured value, calculation output or assumption. Review the weakest evidence first. If an assumption can change safety, compliance, interchangeability or capacity, it must be resolved before release rather than buried in a calculation note.

Evidence classQuestionRelease expectation
RequirementWhat must the design do and under which conditions?Approved and traceable
InputWhere did the load, property, tolerance or process limit come from?Source, unit and revision recorded
AnalysisWhich model and assumptions connect input to result?Checkable calculation or simulation
VerificationHow will conformity be demonstrated?Method and acceptance criterion agreed
ValidationWill the solution work for intended users and conditions?Representative use evidence

Common failure modes and recovery actions

1. Watch for

Starting detailed design before interfaces and operating limits are agreed.

Recovery: Return to the governing definition or requirement and restate the decision in one sentence.

2. Watch for

Using catalogue or typical values as though they were certified project inputs.

Recovery: Separate evidence from assumption, assign an owner and set a date for validation.

3. Watch for

Checking nominal performance while ignoring tolerances, degradation and foreseeable misuse.

Recovery: Run a small counterexample, boundary test, pilot or independent check before proceeding.

4. Watch for

Confusing verification of requirements with validation of user need.

Recovery: Record the consequence, decision and rationale, then update the controlled baseline.

5. Watch for

Releasing drawings or procedures without configuration, inspection and change controls.

Recovery: Escalate when the issue affects safety, compliance, acceptance, material value or an agreed tolerance.

Review checklist

  • What function and failure consequence govern this decision?
  • Which inputs are measured, specified, assumed or illustrative?
  • How will conformity be demonstrated and recorded?
  • What change would invalidate the current evidence?
  • Are mandatory requirements distinguished from recommendations and illustrative values?
  • Are sources, assumptions, units, dates and versions recorded closely enough to reproduce the decision?
  • Have safety, legal, ethical, stakeholder and operational consequences been considered at the appropriate level?
  • Is there a named owner and a trigger for review, escalation, change or retirement?

Questions for deeper application

What is the most important distinction a practitioner must preserve when applying SolidWorks API: Add-in, Stand-alone or Hybrid?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

Which assumption about solidworks would change the result most if it proved false?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

What evidence would allow an independent reviewer to reproduce or challenge the conclusion?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

Which boundary, exception or failure case has not yet been tested?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

What must be handed over, monitored or reviewed after the immediate work is complete?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

Authoritative references and use notes

The sources below were selected as institutional or primary guidance for the broader practice. They support the handbook method; they do not imply that every statement or clause in a source applies to every project. Confirm the current edition, jurisdiction, contract and application before treating any requirement as mandatory.

  • SOLIDWORKS Design Help — Dassault Systèmes SOLIDWORKS. Used for feature-based CAD, sketches, structures and manufacturing outputs. Accessed 2026-08-13.
  • NASA Systems Engineering Handbook — NASA. Used for requirements, design, verification, validation and technical management. Accessed 2026-08-13.

Continue learning

SolidWorks API: Event and Notification ArchitectureGuide · Computing & SoftwareNEXT LESSON →SolidWorks API: Planning, Structure and Debugging DisciplineGuide · Computing & SoftwareSolidWorks API: Property Manager Pages and the Control ModelGuide · Computing & SoftwareSolidWorks API: Deployment Methods and Installer EngineeringGuide · Computing & Software
KEVOS · Engineering, manufacturing and project improvement
ArticlesServicesCase studiesAboutContact
© 2026 KEVOS®