Solidworks-Api

The SolidWorks API speaks one language for lengths: meters. Not millimeters. Not inches. Meters, always, regardless of what your document’s unit system displays. This sounds like something you’d learn in the first chapter of any SolidWorks API tutorial, and it is — yet it causes more silent macro failures than any other single issue. The problem is not that developers don’t know about it. The problem is that it bites you in a second way you didn’t expect, in a context you were already confident about. ...

Layer-by-layer manufacturing covers more territory than most engineers realize. Laminated object manufacturing (LOM), sliced tooling blocks for composite layup, sectioned mold plates for waterjet stacking, large-format CNC where layers are cut and stacked — all of these need DXFs at specific Z heights. SolidWorks doesn’t have a “slice and export” button. But there are three workable approaches, and one of them scales with an API. The problem in concrete terms A customer operates a layer-by-layer cutting machine: it takes DXF profiles at fixed Z-height increments (say, 3mm steps), cuts each layer from sheet stock, and stacks them to build up a 3D form. Your job is to deliver fifty DXF files, each representing the cross-section of the part at a different height. ...

You spend ten minutes configuring the DXF export dialog — turning on bend lines, setting the layer map, choosing which sketch entities to include. You close SolidWorks. You open it the next morning and every checkbox is back to the default. Again. This is one of the most reliably frustrating behaviors in SolidWorks, and it has a specific technical reason that most documentation skips over. More importantly, there are three concrete fixes — ranging from a template trick to a four-line API call — that eliminate the problem entirely. ...

A LinkedIn post earlier this year showed a VBA macro compressing a 40-minute manual batch DXF export down to seconds. It drew significant engagement because every SolidWorks engineer who works with sheet metal has written some version of this macro, or knows someone who has. The basic implementation is not complicated. Iterate assembly components, open each part, call ExportToDWG2, close. For clean assemblies with simple sheet metal parts and consistent filenames, it runs reliably. The problems surface when the assembly contains parts that don’t fit the happy path — and most production assemblies do. ...

The SolidWorks API documentation has a warning that stops add-in developers cold: “Only one instance of SQLite can run in SOLIDWORKS process space. SOLIDWORKS maintains a reference to the SQLite singleton. To ensure compatibility, your SOLIDWORKS add-in must use a version of System.Data.SQLite.dll that is the same as the version used by SOLIDWORKS.” If you’ve read that and immediately thought “but Lightning uses SQLite and it works perfectly fine alongside SolidWorks” — your instinct is correct. The documentation is not lying, but it’s describing a narrow problem in language broad enough to sound like a blanket prohibition. Most developers either over-react (abandon SQLite entirely) or under-react (ignore the warning and get lucky). ...

Every few weeks a mold shop posts a job for a Python or C# developer who can automate their SolidWorks mold design pipeline. The scope is usually the same: take an incoming 3D model, run shrinkage, generate parting surfaces, split the core and cavity, and hand off tooling data. The assumption is that because SolidWorks has a documented API, every mold step is scriptable. It isn’t. Some steps map cleanly to IFeatureManager calls. Others still require a human to pick faces in the graphics area. Knowing which is which is the difference between a pipeline that ships and one that spends six months bouncing between the add-in and the user. ...

Engineers are feeding SolidWorks tasks to ChatGPT, Copilot, and Claude and getting working VBA macros back — sometimes. A Reddit post showing a ChatGPT-generated STL export macro pulled 26 upvotes. A separate thread about building an MCP server for the SolidWorks API drew 15 comments. The interest is real, and for good reason: writing a SolidWorks VBA macro from scratch means wrestling with a COM API that has methods taking 23 parameters and returns boolean values that aren’t actually booleans. ...

You add a Syncfusion data grid to your SolidWorks add-in’s WPF panel. It compiles. The DLLs are in your output folder. You launch SolidWorks, and the add-in loads. Then you open the panel and get this: System.Windows.Markup.XamlParseException: Could not load file or assembly 'Syncfusion.SfGrid.WPF, Version=27.2.2.0, Culture=neutral, PublicKeyToken=3d67ed1f87d44c89' or one of its dependencies. Everything compiled. The DLLs are right there in bin\Debug. NuGet copied them. So why can’t WPF find them? The answer involves a fundamental mismatch between how the .NET CLR probes for assemblies and where COM add-ins actually live on disk. We decompiled SolidWorks’ native add-in loader, examined the WPF BAML reader source code, and inspected the CLR’s assembly resolution pipeline to understand exactly why this happens — and how to fix it with five lines of code. ...

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

You’ve clicked inside that left-hand panel in SolidWorks thousands of times. Every time you create an extrude, add a fillet, define a mate, or configure a sheet metal feature, the Property Manager Page slides in from the left with its groups, checkboxes, selection boxes, and blue highlight fields. It looks like a standard Windows control panel. But it isn’t. If you’ve ever tried to build your own PMP through the SolidWorks API, you’ve noticed something strange: you don’t create Windows controls. You call AddControl with a type enum and get back a COM interface. You can’t set a font. You can’t subclass the window. You can’t attach a debugger to the control’s HWND the way you would with a normal Windows button. The PMP controls don’t behave like anything else on Windows. ...