New SQLite mixed assemblies

The downloads page now contains "mixed mode" downloads for all variations of System.Data.SQLite, that work the same way as earlier versions of SQLite i.e. no requirement to also include SQLite.Interop.dll in your project.

The trick is - look for the word "bundle" in the download links

e.g. sqlite-netFx35-setup-bundle-x86-2008-1.0.76.0.exe

You will also see that the description text for these links begins with "This setup package features the mixed-mode assembly".

I got burned because I didn't realize that this really means "download this one if you want it to work the way it always did before".

Having no idea what was meant by a mixed-mode assembly, the other links seemed like a better option - because they claim "This setup package will install all the necessary runtime components and dependencies".

Also note that the only way to tell if you've gotten the "wrong" one is by file size. The DLLs have exactly the same name, and exactly the same version number. The mixed-mode version is much bigger - around 700K. The other one is around 160K.

What a mess...

I found the solution. The problem was due to a known issue with SQLite.Interop.dll.

This is the workaround from that worked for me.

Using Dependency Walker from http://dependencywalker.com/ to look at SQLite.Interop.dll (x86 and x64) shows that it depends on MSVCR100.dll.

The old 1.0.66.0 version of System.Data.SQLite.dll does not have this dependency. With the current build, we would have to redistribute that MSVCR100.dll also or run an installer from Microsoft.

Solution: From: Missing msvcr100.dll

Use static linking. In the SQLite.Interop Visual Studio project. Go to this Properties setting: Project -> Properties -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library and change the value to Multi-threaded (/MT). (The current source code (1.0.71.0) has Multi-threaded DLL (/MD) which causes the dll to rely on MSVCR100.dll and the DLLImport (and LoadLibary()) to fail when users do not have it).

I believe static linking should be changed so it is the default for SQLite.Interop.dll.

I had the same issue, in a plugin for a different application. In my case I solved it by modifying the environment variable PreLoadSQLite_BaseDirectory before referencing SQLite for the first time.

// Make SQLite work... (loading dll from e.g. x64/SQLite.Interop.dll)System.Environment.SetEnvironmentVariable("PreLoadSQLite_BaseDirectory", System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location));Sql.Data.SQLite...

I don't see why this was required though, as I thought PreLoadSQLite_BaseDirectory (well, the corresponding internal variable) would default to the location of the System.Data.SQLite.dll file.