Cad-Internals

A forum thread from 2026-08-06 captures the problem precisely: a user has a manual workflow — roll back to a feature state, show the body, align the view normal to the target face, then do File > Save As DXF. It works. They then try to replicate it in VBA using IPartDoc.ExportToDWG2, pass the same file path, and get either a failed export (False return, no error) or a DXF that contains nothing. No accepted answer exists because the root cause isn’t obvious from the API documentation. ...

Open Task Manager during almost any SolidWorks session and you’ll find sldProcMon.exe sitting quietly next to SLDWORKS.exe. Most of the time it’s invisible — a few megabytes of RAM, no window, no icon you’d notice. Then, on some machines, it pins a full CPU core at idle, spawns a fresh copy every time you relaunch SolidWorks without cleaning up the old one, or — in scripted and remote-desktop automation — climbs to 90%+ CPU and refuses to let go. ...

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

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

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

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

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

You click “Insert View” in FreeCAD’s TechDraw workbench, point it at a 3D part, and a few seconds later a clean 2D projection appears on the drawing page. Hidden lines are dashed, silhouettes follow curved surfaces, and section views show cross-hatched cut faces. It looks like the same thing SolidWorks does. And at a high level, it is — both systems solve the same fundamental problem: project a 3D solid onto a 2D plane, figure out which edges are visible, and draw the result. ...

Every SolidWorks user has opened a .SLDDRW file thousands of times. You place views, add dimensions, print to PDF, send it to the shop. But what’s actually inside that file? Is it vector graphics — maybe SVG behind the scenes? Is it a database of coordinates? How does a drawing “know” what the 3D model looks like from the front? We decompiled the SolidWorks interop DLLs, inspected exported symbols from native C++ libraries, and dug through the API documentation to answer these questions. Here’s what we found. ...

Every mechanical engineer who works with sheet metal in SolidWorks has clicked Export DXF/DWG hundreds of times. The flat pattern appears, a file lands on disk, and you send it to the laser cutter. But what actually happens between clicking that button and getting a flat DXF? Why is it slow? And why does the orientation sometimes feel random? We spent time digging into the SolidWorks API documentation, decompiling DLLs, and examining exported symbols to understand the full pipeline — the same approach we used when investigating how SolidWorks drawing files store geometry internally. Here’s what we found. ...