Csharp

A question that surfaces repeatedly on r/MechanicalEngineering and r/SolidWorks: how much C# vs VBA do you actually need for a SolidWorks CAD automation role? The answers in those threads range from “VBA is enough” to “you need modern .NET”—and both are correct, depending on what the role actually involves. The real answer is architectural: VBA macros and C# COM add-ins solve different problems. Understanding the boundary between them—and being able to explain it—is what separates candidates who have run a few macros from those who can design production automation systems. ...

A SolidWorks macro gets you 80 percent of the way there. It can open files, traverse assemblies, read custom properties, save DXF, and close — all without writing a line of C#. The VBA IDE ships inside SolidWorks, the API reference is documented, and a working batch export macro can be running in an afternoon. Then the macro breaks in a way that a one-line fix will not solve. Or someone needs it on fifteen workstations, or the team wants a toolbar button, or the workflow needs to respond to file saves without being manually invoked. That is when engineers discover that “just adding a button” requires a complete architectural shift. Macros and add-ins are not on the same continuum — they differ at the design level, and the capabilities that matter most to production workflows sit entirely on the add-in side of that line. ...