System.Data.SQLite: Frequently Asked Questions

The release schedule for the System.Data.SQLite project is roughly synchronized (within about two or three weeks) with that of the SQLite core itself. The release history for the System.Data.SQLite project is here.

(2) When are you planning on adding feature "X"?

This question is hard to answer precisely. It depends on a number of factors, including but not limited to:

Can the feature be implemented in a backward compatible manner?

Can the feature be implemented in a portable fashion for all the currently supported versions of the .NET Framework and/or Visual Studio?

Does the feature fit well with the current design of the project?

How much time will it take to design, implement, and test the feature?

Will the feature benefit the entire community or only a tiny subset thereof?

(3) What versions of .NET Framework are supported?

The .NET Framework 2.0 SP2 (or higher) for the System.Data.SQLite assembly.

The .NET Framework 3.5 SP1 (or higher) for the System.Data.SQLite.Linq assembly.

The .NET Framework 4.0 (or higher) for the System.Data.SQLite.EF6 assembly.

All sub-projects are fully supported with the .NET Framework 4.0.

All sub-projects are fully supported with the .NET Framework 4.5.

(4) What versions of Visual Studio are supported?

Currently, Visual Studio 2005, 2008, 2010, 2012, 2013, 2015, and 2017 are supported, including the "Express" editions; however, in order to build the entire solution, including the necessary native code, the "Professional" edition (or higher) is required. It may be possible to install both Visual C# Express and Visual C++ Express and then build the corresponding sub-projects via their respective integrated development environments (IDE); however, this configuration has not been tested. The design-time components are no longer supported for the Express editions due to licensing restrictions. Due to changes in the Visual Studio package installation model, the design-time components do not support Visual Studio 2017 and later versions. Also, as of May 1, 2017, the design-time components are no longer officially supported.

(5) Are NuGet packages available?

Yes.

These are the primary NuGet packages:

System.Data.SQLite: The SQLite database engine for both x86 and x64 along with the ADO.NET provider, including support for LINQ and Entity Framework 6.

System.Data.SQLite.Core: The SQLite database engine for both x86 and x64 along with the ADO.NET provider.

System.Data.SQLite.Core.MSIL: Just the managed ADO.NET provider for SQLite.

System.Data.SQLite.EF6: Just support for Entity Framework 6 using System.Data.SQLite.

System.Data.SQLite.Linq: Just support for LINQ using System.Data.SQLite.

Stub.System.Data.SQLite.Core.NetFramework: The SQLite database engine for both x86 and x64 along with the ADO.NET provider. This package targets the desktop .NET Framework.

Stub.System.Data.SQLite.Core.NetStandard: The SQLite database engine for both x86 and x64 along with the ADO.NET provider. This package targets the .NET Standard 2.x.

These NuGet packages may contain "beta" code and are not intended for production use.

System.Data.SQLite.Beta: The SQLite database engine for both x86 and x64 along with the ADO.NET provider, including support for LINQ and Entity Framework 6.

System.Data.SQLite.Core.Beta: The SQLite database engine for both x86 and x64 along with the ADO.NET provider.

System.Data.SQLite.Core.MSIL.Beta: Just the managed ADO.NET provider for SQLite.

System.Data.SQLite.EF6.Beta: Just support for Entity Framework 6 using System.Data.SQLite.

System.Data.SQLite.Linq.Beta: Just support for LINQ using System.Data.SQLite.

System.Data.SQLite.MSIL.Beta: Just the managed ADO.NET provider for SQLite.

These NuGet packages may contain pre-release code and are not intended for production use.

System.Data.SQLite.Core.Test: The SQLite database engine for both x86 and x64 along with the ADO.NET provider.

System.Data.SQLite.Core.MSIL.Test: Just the managed ADO.NET provider for SQLite.

System.Data.SQLite.EF6.Test: Just support for Entity Framework 6 using System.Data.SQLite.

System.Data.SQLite.Linq.Test: Just support for LINQ using System.Data.SQLite.

System.Data.SQLite.MSIL.Test: Just the managed ADO.NET provider for SQLite.

System.Data.SQLite.Test: The SQLite database engine for both x86 and x64 along with the ADO.NET provider, including support for LINQ and Entity Framework 6.

Finally, there are legacy NuGet packages for backwards compatibility. If possible, projects using these should be updated to use either the "System.Data.SQLite" or "System.Data.SQLite.Core" package instead of using these legacy packages. These legacy NuGet packages should not be used for new projects and may stop receiving updates in the future.

System.Data.SQLite.MSIL: Just the managed ADO.NET provider for SQLite.

System.Data.SQLite.x86: The SQLite database engine combined with a complete ADO.NET provider all rolled into a single mixed-mode assembly for x86.

System.Data.SQLite.x64: The SQLite database engine combined with a complete ADO.NET provider all rolled into a single mixed-mode assembly for x64.

(6) How do I build the binaries for Mono?

This is documented on the build procedures page. Alternatively, there is now a pre-built binary package for Mono on the downloads page.

(7) How do I build the binaries for .NET Compact Framework?

This is documented on the release procedures page.

(8) How do I install System.Data.SQLite on a development machine?

Strictly speaking, there is no need to install System.Data.SQLite on any development machine (e.g. via the setup). The recommended way to use the assemblies is:

Download the precompiled binary package for your target framework and processor architecture (e.g. 32-bit x86, .NET Framework 2.0).

Extract the package to a directory named "Externals" inside your project directory.

Add a reference to the "System.Data.SQLite" assembly from the "Externals" directory.

If necessary (i.e. you require LINQ support), also add a reference to the "System.Data.SQLite.Linq" assembly from the "Externals" directory.

If necessary (i.e. you require EF6 support), also add a reference to the "System.Data.SQLite.EF6" assembly from the "Externals" directory.

Alternatively, when using Visual Studio 2010 or later, you can simply use the NuGet package that corresponds to your target processor architecture. Installing the assemblies into the Global Assembly Cache is not recommended as it may cause conflicts with other applications installed on the machine.

(9) How do I install System.Data.SQLite on end-user machines?

Strictly speaking, there is no need to install System.Data.SQLite on any end-user machine (e.g. via the setup). The recommended way to deploy the assemblies is "application local" (i.e. copy them to the directory the application is installed to). Installing the assemblies into the Global Assembly Cache is not recommended as it may cause conflicts with other applications installed on the machine.

(10) Do I need to add an assembly reference to the "sqlite3.dll" or "SQLite.Interop.dll" in my project?

No, because they are not managed assemblies and contain no managed code.

(11) Why do I get a DllNotFoundException (for "sqlite3.dll" or "SQLite.Interop.dll") when trying to run my application?

Either the named dynamic link library (DLL) cannot be located or it cannot be loaded due to missing dependencies. Make sure the named dynamic link library is located in the application directory or a directory along the system PATH and try again. Also, be sure the necessary Visual C++ runtime redistributable has been installed unless you are using a dynamic link library that was built statically linked to it.

(12) Why do I get a BadImageFormatException (for "sqlite3.dll" or "SQLite.Interop.dll") when trying to run my application?

The named dynamic link library (DLL) contains native code that was built for a processor architecture that is not compatible with the current process (e.g. you cannot load a 32-bit dynamic link library into a 64-bit process or vice-versa). Another explanation is that the named dynamic link library was built for a later version of the CLR than is available in the current process (e.g. you cannot load an assembly built for the .NET Framework 4.0 into a .NET Framework 2.0 process, regardless of the processor architecture).

(13) Why do I get the error "This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded."?

Because the assembly was built for the .NET Framework 4.0 and you are trying to load it into a process that is using the .NET Framework 2.0.

(14) What is a mixed-mode assembly?

A mixed-mode assembly is a dynamic link library that contains both managed code and native code for a particular processor architecture. Since it contains native code it can only be loaded into a process that matches the processor architecture it was compiled for. Also see this StackOverflow question.

(15) What is a "bundle" package (i.e. from the downloads page)?

The "bundle" packages listed on the downloads page contains the System.Data.SQLite mixed-mode assembly in a file named "System.Data.SQLite.dll" (see question #14) instead of separate "System.Data.SQLite.dll" and "SQLite.Interop.dll" files to contain the managed code and native code, respectively.

(16) What is the difference between the "Setup" and "Precompiled Binary" packages (i.e. from the downloads page)?

The "Setup" packages are designed to install the necessary files, optionally installing the assemblies into the Global Assembly Cache, generating native images for the managed assemblies via Ngen, adding Start Menu shortcuts, modifying the .NET Framework machine configuration files to register the ADO.NET provider, and installing the design-time components for Visual Studio. The "Precompiled Binary" packages are simply ZIP files that contain all the binaries compiled for a particular .NET Framework and processor architecture.

(17) Why is System.Data.SQLite leaking memory, resources, etc?

All System.Data.SQLite objects that implement IDisposable, either directly or indirectly, should be explicitly disposed when they are no longer needed. If this is the case and you are still seeing a leak of some kind, please file a ticket.

(18) What are the support options for System.Data.SQLite?

This is discussed on the support page.

(19) When the solution is loaded in Visual Studio, why do no files show up for several of the projects in the Solution Explorer window?

Several of the sub-projects (i.e. primarily those that build variants of the System.Data.SQLite assembly) share an MSBuild "targets" file that contains the actual references to the C# source code files. Unfortunately, due to limitations on how Visual Studio reads and interprets MSBuild files at design-time, the C# source code files do not show up in the Solution Explorer window. This limitation is largely cosmetic and does not impact the correctness of the build process itself, whether in Visual Studio or when using MSBuild on the command line.

(20) When the System.Data.SQLite project is compiled and run from inside Visual Studio, why do I get a DllNotFoundException or a BadImageFormatException (for "sqlite3.dll" or "SQLite.Interop.dll") when trying to run or debug the application?

When compiling and running a solution from within Visual Studio that uses the System.Data.SQLite project (including the test project), it is very important to select the correct build configuration and platform. First, managed applications to be debugged inside Visual Studio cannot use the mixed-mode assembly (i.e. because it is always compiled to the platform-specific build output directory). This is necessary to properly support building binaries for multiple platforms using the same source project files. Therefore, only the "DebugNativeOnly" or "ReleaseNativeOnly" build configurations should be selected when running a managed application from inside Visual Studio that relies upon the System.Data.SQLite assembly. These build configurations contain a custom post-build step that copies the required native assembly to the managed output directory (i.e. to enable running the managed binaries in-place). However, this post-build step will only be performed if the selected platform matches that of the operating system (e.g. "Win32" for 32-bit Windows and "x64" for 64-bit Windows). Therefore, it is good practice to double-check the selected build platform against the operating system prior to attempting to run a managed project in the solution.

(21) Is this behavior a bug? -OR- Is there a quick way to view the various lists of tickets for the System.Data.SQLite project?

If any behavior is observed that appears to be a bug, it may be reported via the SQLite Forum or by filing a ticket. Prior to taking one of these steps, it is always prudent to check the various lists of previously filed tickets to see if the behavior being observed has already been reported and possibly fixed in a subsequent release.

(22) Since upgrading a project to use System.Data.SQLite version 1.0.82.0 (or later), the database file is still locked after all its connections have been closed. Why is this happening?

As of version 1.0.82.0, the native resources for a SQLiteConnection object, including any native locks on the underlying file, are not fully released until all SQLiteCommand, SQLiteDataReader, SQLiteStatement, and SQLiteBackup objects associated with that SQLiteConnection object have also been disposed. These changes were made to allow the SQLite native resource management to integrate better with the garbage collection semantics used by the Common Language Runtime. Allowing native SQLite resources to be released in a non-deterministic order is accomplished through careful use of the sqlite3_close_v2() core native library routine.