solidworks-addin

name

solidworks-addin

description

Build AND debug SOLIDWORKS API automation in C#/.NET (or VBA macros) — scaffold ISwAddin add-ins, register CommandManager tabs/buttons, handle COM registration, drive swApp from standalone scripts, and implement or fix batch-automation and modeling code (custom properties, materials, batch PDF/STEP/DWG export, geometry creation, coordinate systems, hole/point generation from CSV, assembly/component traversal, mirror parts). Use this skill whenever the user wants to automate SOLIDWORKS, write OR debug a SOLIDWORKS macro/add-in/automation script, extend SOLIDWORKS with a custom tool or button, look up or fix a SOLIDWORKS API call (e.g. FeatureExtrusion, HoleWizard, SaveAs, SelectByID2, ForceRebuild, or any ISldWorks/IModelDoc2/IPartDoc/IAssemblyDoc/IDrawingDoc method), figure out why API-created geometry is wrong (e.g. dimensions off by ~1000× from SI-unit mistakes) or why a CommandManager callback/button does nothing, traverse or batch-edit components in an assembly programmatically, batch-process SLDPRT/SLDASM/SLDDRW files, or clone utility features like those in SpeedWorks. Trigger even when the user just says "SW macro", "swApp", "솔리드웍스 애드인/매크로/자동화/스크립트", or names an interop type — and even for short debugging questions about existing SOLIDWORKS API code. This covers SOLIDWORKS only — not AutoCAD, Inventor, Fusion 360, NX, or non-SOLIDWORKS COM/Office add-ins.

SOLIDWORKS Add-in Development (C#/.NET)

This skill builds SOLIDWORKS API add-ins — DLLs that load inside SOLIDWORKS, add buttons to the CommandManager, and automate work through the API. Use it for both full add-ins and standalone automation (macros, batch scripts that drive swApp).

What an add-in actually is

A SOLIDWORKS add-in is a COM-visible .NET class that implements ISwAddin (SolidWorks.Interop.swpublished.SwAddin). SOLIDWORKS discovers it via registry keys, calls ConnectToSW on load, and the add-in then registers UI and responds to callbacks. Everything else — creating geometry, editing properties, exporting files — is plain API calls against the interop objects SOLIDWORKS hands you.

The model to keep in your head:

SOLIDWORKS process
  └─ loads your DLL (COM, registry-registered)
       └─ ConnectToSW(swApp, cookie)   ← entry point, you get ISldWorks
            ├─ register CommandManager group + buttons (each button → callback name)
            └─ user clicks button → SOLIDWORKS calls your callback method by name
                 └─ callback does API work on the active IModelDoc2

Hard constraints (state these to the user up front if relevant)

• Requires a licensed SOLIDWORKS install. The API is COM in-process — there is no standalone engine. Code can only be built referencing the interop assemblies, and only runs on a machine with SOLIDWORKS. You cannot test execution in this environment; you produce code the user runs on their CAD box.
• Windows + .NET Framework, x64. Target .NET Framework 4.7.1+ (matches the user's environment). Build as x64 (or "Any CPU" with Prefer-32-bit off) — SOLIDWORKS is 64-bit.
• Internal units are SI: meters, radians, kilograms. A "100 mm" box is 0.1. This is the #1 source of silently-wrong geometry. Convert at the boundary, never mid-calculation.
• COM lifetime matters: release interop objects you obtain in loops with Marshal.ReleaseComObject to avoid SOLIDWORKS holding files open / memory bloat during batch runs. See references/pitfalls.md.

Workflow for generating an add-in

1. Clarify scope — which features, and add-in (persistent UI buttons) vs. one-shot macro/console app (drives swApp, no UI registration). Batch-file tools are often better as a button that opens a dialog; geometry helpers too.
2. Scaffold the project — produce the .csproj, the SwAddin.cs entry point with ConnectToSW/DisconnectFromSW, COM register/unregister functions, and CommandManager setup. Full working template is in references/scaffold-template.md. Copy it, then strip buttons the user doesn't need rather than writing from scratch.
3. Implement each feature as a callback method. Map the feature to the right API object and call flow using references/api-recipes.md — it's organized by the SpeedWorks-style feature groups (batch operations, modeling) the user cares about, with the exact interop types and method names.
4. Wire build + deploy — register for COM interop, set the registry keys (the [ComRegisterFunction] does this), and explain the debug setup (attach to SLDWORKS.exe). See references/build-deploy.md.
5. Flag what you couldn't verify — you cannot run SOLIDWORKS here. Method names below are real, but exact parameter lists and enum values drift across API versions. Tell the user which signatures to confirm against the local API help (SOLIDWORKS API Help, or the online API docs), and never invent an enum member you're unsure of — point them to the swconst enum instead.

Reference files

Read the one matching the task instead of loading everything:

• references/scaffold-template.md — complete, working add-in skeleton: .csproj, SwAddin.cs, CommandManager registration, COM register/unregister, a sample button + callback. Start here for any new add-in.
• references/api-recipes.md — feature implementation recipes by group. Batch operations (custom properties, materials, batch export PDF/DWG/STEP, rebuild, configuration/component traversal) and modeling (primitives via extrude/revolve, coordinate systems, batch points from CSV, batch holes, 3D-sketch conversion, mirror part, performance toggles). Each entry: which interop object, the call sequence, and gotchas.
• references/build-deploy.md — project settings, COM-interop registration, the registry keys SOLIDWORKS reads, signing, debugging (attach to process), and packaging/installer notes.
• references/pitfalls.md — the recurring traps: units, COM release, version signature drift, selection-based vs. direct API, rebuild/EditRebuild timing, silent failures when no document is open, threading/STA.

Style

The user is a senior mechanical/optical defense engineer. Be concise and direct — give the call flow and the gotcha, not API tutorials. When producing code, make it compile-ready C# (proper usings, COM attributes, null checks for "no active doc"), match the scaffold's conventions, and comment only the non-obvious (unit conversions, why a COM object is released, version caveats).