Com

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

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