Solidworks

Two posts in the last week on r/SolidWorks surface the same class of bug: DXFs that look fine in SolidWorks land corrupted downstream. One user watched bend lines lean off-axis on a small flange until they dropped the end point merging tolerance from 1 to 0.1. Another spent a week re-ticking the entity checkboxes on every export because SolidWorks does not remember them. Both problems come from defaults that SolidWorks ships and almost nobody documents — buried in a bitmask you only see if you touch the API. ...

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

When You’re Tired of Doing the Same Export Steps on Repeat If you’ve spent any real time looking for ways to automate SolidWorks export workflows, you’ve probably come across both CadShift and CAD+ by Xarial. Both tools aim to cut down the manual grind of repetitive CAD tasks — but they approach the problem from very different angles. This comparison is for engineers actively evaluating both options who want a straight answer: what does each tool actually do, where does each one fall short, and which one makes more sense for your situation. ...

You click “Fillet,” pick an edge, type a radius, and hit the green check. The edge rounds off. Done. Until it isn’t. Until you get “Fillet operation failed” on a perfectly reasonable-looking edge. Or until the same 2mm radius works on one edge but blows up on the adjacent one. Or until your model rebuilds fine in SolidWorks but the same STEP file fillets differently in Inventor. These aren’t random bugs. They’re the predictable result of three completely different geometric kernels making three completely different decisions about how to roll a ball along an edge. We decompiled the DLLs, read the exported symbols, and walked through the open-source code to see what’s actually happening. ...

The Export Problem Nobody Talks About You’ve finished the design. The model is clean, the drawing is done — and now comes the part nobody put on the project timeline: exporting everything. Open part. Save As. Choose format. Set options. Confirm. Repeat. Forty times. If you’ve spent any real time in SolidWorks, you know this routine. It’s not hard, exactly — it’s just slow, repetitive, and surprisingly easy to get wrong. One bad export setting, one missed bend line, one file dropped in the wrong folder, and suddenly you’re fielding questions from manufacturing because they got bad data. ...

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

SolidWorks PDM is doing what it was designed to do: managing file versions, controlling access, and keeping your CAD data from becoming a chaotic mess of part_v3_FINAL_real_final.sldprt files. Most teams that implement it see immediate benefits in file control. But then the engineer emails the shop floor a DXF with a hand-typed filename. Procurement is working from a BOM that was exported two weeks ago. The fabrication team has a different quantity listed than what’s in the current assembly. PDM didn’t prevent any of this. ...

Every major SolidWorks release changes something under the hood that nobody asked for. The 2025 release is no exception, and this time it’s the flat pattern engine that got reworked. If you’ve upgraded recently and noticed that your DXF exports look different, your corner reliefs have mysterious tear lines, or your flatten sub-features are behaving strangely — you’re not imagining things. These are real changes in how SolidWorks 2025 handles sheet metal internally, and they affect anyone who relies on consistent DXF output for fabrication. ...

You just built a SolidWorks add-in. Before it can run, you need to register it as a COM server with regasm.exe, write registry keys under HKEY_LOCAL_MACHINE, and make sure your class has [ComVisible(true)] and a [Guid] attribute. You need admin privileges. You’re locked to .NET Framework 4.x. And if the registration goes wrong, you get a cryptic swRegistrationError and nothing loads. Meanwhile, your colleague building an Inventor add-in drops a .addin XML file into a folder, points it at a .NET 8 assembly, and it just works. No regasm, no registry, no admin rights. ...