SolidWorks SQLite Add-in Conflict — What the One-Instance-Per-Process Rule Actually Means

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

Here’s what is actually happening.

First: a simple analogy

Think of the SolidWorks process like a classroom. Every add-in keeps its code and data in the room alongside SolidWorks’ own code. Windows tracks which code modules are already in the room using name tags — specifically, the full file path each DLL was loaded from.

When a second student tries to bring in a toy with the same name tag, Windows says: “We already have one of those” and hands them the first copy. They share it. If both students expected exactly the same version of that toy but got a slightly different one, pressing buttons might do unexpected things. That is the crash risk.

The rule is not “the classroom can only contain one toy of this type.” The rule is “you cannot have two toys with the same name tag.” These are very different restrictions with very different consequences.

What SolidWorks actually ships

The first thing to check is what SolidWorks itself installs. Digging into a SolidWorks 2024 installation reveals something the documentation glosses over completely:

Main SolidWorks directory:

SOLIDWORKS CAM subdirectory:

SolidWorks ships two different versions of System.Data.SQLite.dll in its own installation — 1.0.111 and 1.0.105. Both run in the same process without crashing. This alone tells you the “must match exactly” rule isn’t the whole story.

The warning describes two different problems

The documentation’s single paragraph covers two technically separate issues that have very different risk levels.

Problem 1: Native DLL collision (the real crash risk)

sqlite3.dll is a native C library. When Windows loads a native DLL, it uses the file path as the identity key. If your add-in loads sqlite3.dll from a path that SolidWorks has already loaded it from — no problem, you get the same module, same reference count. But if your add-in loads a different build of sqlite3.dll under the same filename from a different directory, you hit load-order ambiguity. The first copy into the process wins. If the two builds have incompatible internal function signatures, memory corruption follows.

This is the documented real-world incident. The notorious “SOLIDWORKS CAM detected an issue with the SQLite DB Engine” crash was caused by Dell Backup and Recovery installing a conflicting SQLite.Interop.dll into a system directory. That file loaded before CAM’s copy. Native filename collision, not a version number mismatch.

Problem 2: Managed assembly version mismatch (lower risk than it sounds)

System.Data.SQLite.dll is a strong-named .NET assembly with a public key token. The CLR caches strong-named assemblies per AppDomain — once loaded, the same identity resolves to the same object. If SolidWorks has already loaded version 1.0.111 and your add-in’s manifest says it needs 1.0.116, the CLR silently gives your add-in 1.0.111.

Whether this causes a crash depends on what your code actually does with the library. If you use standard IDbConnection/IDbCommand patterns — the stable ADO.NET surface that almost every SQLite add-in uses — the API has not changed meaningfully across minor versions. The mismatch resolves quietly. If you depend on version-specific behavior or internal System.Data.SQLite-only APIs, you might hit a problem. But generic database access code does not.

The CLR assembly loading mechanics here are the same as in any COM host. If you’ve dealt with WPF assembly resolution failures in SolidWorks add-ins, you’ll recognize the pattern: the host process’ AppDomain rules apply, not your add-in’s local directory rules.

Why Lightning works without issues

Lightning by CAD Booster is one of the most popular SolidWorks productivity add-ins, and it uses its own SQLite database internally. The Lightning developer stated directly: “I use my own SQLite version and have never noticed any problems.”

Here’s why it works:

1. It ships SQLite.Interop.dll, not sqlite3.dll. Different filename. Windows treats it as a completely separate module. No name collision with SolidWorks’ sqlite3.dll.
2. It loads from a private directory. Even if filenames matched, the different file path means a different HMODULE identity.
3. It uses stable ADO.NET APIs. The CLR-level version mismatch, if it occurs, resolves silently because the API surface used is stable.

All three of these things together — and the NuGet package for System.Data.SQLite does all of them by default.

What the warning should have said

The actual restriction, stated precisely:

Do not ship a file named sqlite3.dll that loads into SolidWorks’ process alongside SolidWorks’ own sqlite3.dll. Use SQLite.Interop.dll as your native interop filename, load it from your add-in’s own private directory, and use standard ADO.NET APIs.

That is it. Everything else is survivable.

Practical checklist for add-in developers

If you’re building a SolidWorks add-in and want to use SQLite, here’s how to do it safely:

Use the NuGet package. The System.Data.SQLite NuGet package ships SQLite.Interop.dll as its native component — not sqlite3.dll. This sidesteps the native filename collision by design.

Install into your add-in’s own directory. Do not copy SQLite files into the SolidWorks install directory. Let your add-in’s private folder be the load point.

Use IDbConnection/IDbCommand interfaces. The more your code resembles standard ADO.NET, the less a managed version mismatch matters.

Test with SOLIDWORKS CAM installed. CAM ships its own SQLite version and is the most realistic test of the managed-version-mismatch scenario. If it works with CAM present, it’ll work anywhere.

Consider alternatives for small datasets. If your database is relatively simple — a list of parts, a settings file, a lookup table — a JSON file or a lightweight key-value store removes this concern entirely. For CadShift’s fastener database, we use JSON files for exactly this reason: the data structure fits naturally and it eliminates one more variable in someone else’s SolidWorks environment.

The bottom line

The SolidWorks documentation describes a real problem — native DLL name collisions can absolutely crash the process — but phrases it as a blanket prohibition on using SQLite in add-ins. The reality is narrower. SOLIDWORKS CAM itself ships a different version of System.Data.SQLite than the main process. Multiple popular add-ins use SQLite without issues. The NuGet package handles the naming correctly by default.

Use the NuGet package, load from a private directory, stick to standard APIs. You don’t need to match SolidWorks’ version exactly. You just need to avoid bringing a toy with the same name tag.