← ClaudeAtlas

solidworks-addinlisted

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/SLDAS
jsb4702-glitch/verification-harness · ★ 7 · AI & Automation · score 76
Install: claude install-skill jsb4702-glitch/verification-harness
# 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