Dotnet

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