System.Data.SQLite

Login
This project makes use of Eagle, provided by Mistachkin Systems.
Eagle: Secure Software Automation

Build Procedures

Follow these steps to build the System.Data.SQLite ("SDS") binaries. Unless otherwise noted, all steps need to be done in the order specified.

You will need a Visual Studio 2005, Visual Studio 2005 SP1, Visual Studio 2008, Visual Studio 2008 SP1, Visual Studio 2010, Visual Studio 2010 SP1, Visual Studio 2012, Visual Studio 2013, Visual Studio 2015, or Visual Studio 2017 development environment for this build. In order to build both the managed (C#) and native projects (C++) for a particular solution together, the "Professional Edition" (or better) of that particular version of Visual Studio is required.

The new build system has been setup using modular solution, project, and property files.

In general, all files with 2005, 2008, 2010, 2012, 2013, 2015, or 2017 in the name (e.g. "SQLite.Interop.2005.vcproj") are files for Visual Studio 2005, Visual Studio 2008, Visual Studio 2010, Visual Studio 2012, Visual Studio 2013, Visual Studio 2015, or Visual Studio 2017, respectively. Files ending in ".vsprops" are property files for a Visual Studio 2005 or Visual Studio 2008 project. Files ending in ".props" are property files for a the Visual Studio 2010, Visual Studio 2012, Visual Studio 2013, Visual Studio 2015, or Visual Studio 2017 project. When making changes, they should be made to the corresponding files for all applicable versions of Visual Studio.

You can either manually build the System.Data.SQLite binaries using one of the supplied Visual Studio solutions or follow the steps outlined in the Automated Build section below.

Build Assumptions & Prerequisites

  1. We want to ship managed binaries that rely on the .NET Framework 2.0 SP2 (or for the LINQ assembly, the .NET Framework 3.5 SP1). The .NET Framework 2.0 is very widely deployed and binaries produced for it can also be referenced and used successfully from projects using the .NET Framework 4.0.
  2. We want to ship native binaries that rely on the Visual C++ 2008 Runtime.
  3. We want to ship the separate managed-only "System.Data.SQLite.dll" assembly and the "SQLite.Interop.dll" native library. This will make it easier to maintain and deploy the included core SQLite code (in the "SQLite.Interop.dll" native library). We also want to ship the "monster DLL" (i.e. the mixed-mode "System.Data.SQLite.dll" assembly that includes all the necessary native and managed code). This will make it easier for developers that wish to register the assembly in the Global Assembly Cache (GAC).
  4. The machine used to prepare the official releases will have the .NET Framework 3.5 SP1 and the corresponding SDK installed.
  5. The machine used to prepare the official releases will have Inno Setup 5.5.5 or higher installed in "%ProgramFiles%\Inno Setup 5" or "%ProgramFiles(x86)%\Inno Setup 5" for an 64-bit machines. Alternatively, the Inno Setup directory may be included in the PATH environment variable.
  6. The string "<root>" represents the root directory of your local source tree (i.e. the working check-out directory) for the System.Data.SQLite project.
  7. The string "<year>" represents the version of Visual Studio being used (e.g. 2005, 2008, 2010, 2012, 2013, 2015, or 2017).
  8. For now, the project will always be built on modern Windows using the .NET Framework even when they will eventually be deployed to run under Mono on Unix.

All Builds

  1. Make sure the version information is correct for SQLite in all of the following files (this step should not be necessary when using source code checked out from the official repository):
    • <root>\SQLite.Interop\props\sqlite3.vsprops
    • <root>\SQLite.Interop\props\sqlite3.props
    You'll need to update the SQLITE_MANIFEST_VERSION and SQLITE_RC_VERSION properties. This version number should track the release versions of SQLite (i.e. 3.7.x).
  2. Make sure the version information is correct for System.Data.SQLite in the following files (this step should not be necessary when using source code checked out from the official repository):
    • <root>\readme.htm
    • <root>\Doc\Extra\Provider\dbfactorysupport.html
    • <root>\Doc\Extra\Provider\welcome.html
    • <root>\NuGet\SQLite.nuspec
    • <root>\NuGet\SQLite.Beta.nuspec
    • <root>\NuGet\SQLite.Core.nuspec
    • <root>\NuGet\SQLite.Core.Beta.nuspec
    • <root>\NuGet\SQLite.Core.Test.nuspec
    • <root>\NuGet\SQLite.Core.MSIL.nuspec
    • <root>\NuGet\SQLite.Core.MSIL.Beta.nuspec
    • <root>\NuGet\SQLite.Core.MSIL.Test.nuspec
    • <root>\NuGet\SQLite.Core.NetFramework.nuspec
    • <root>\NuGet\SQLite.Core.NetStandard.nuspec
    • <root>\NuGet\SQLite.EF6.nuspec
    • <root>\NuGet\SQLite.EF6.Beta.nuspec
    • <root>\NuGet\SQLite.EF6.Test.nuspec
    • <root>\NuGet\SQLite.Linq.nuspec
    • <root>\NuGet\SQLite.Linq.Beta.nuspec
    • <root>\NuGet\SQLite.Linq.Test.nuspec
    • <root>\NuGet\SQLite.MSIL.nuspec
    • <root>\NuGet\SQLite.MSIL.Beta.nuspec
    • <root>\NuGet\SQLite.MSIL.Test.nuspec
    • <root>\NuGet\SQLite.Test.nuspec
    • <root>\NuGet\SQLite.x86.nuspec
    • <root>\NuGet\SQLite.x64.nuspec
    • <root>\SQLite.Designer\AssemblyInfo.cs
    • <root>\SQLite.Designer\source.extension.vsixmanifest
    • <root>\SQLite.Interop\props\SQLite.Interop.2005.vsprops
    • <root>\SQLite.Interop\props\SQLite.Interop.2008.vsprops
    • <root>\SQLite.Interop\props\SQLite.Interop.2010.props
    • <root>\SQLite.Interop\props\SQLite.Interop.2012.props
    • <root>\SQLite.Interop\props\SQLite.Interop.2013.props
    • <root>\SQLite.Interop\props\SQLite.Interop.2015.props
    • <root>\SQLite.Interop\props\SQLite.Interop.2017.props
    • <root>\SQLite.Interop\src\generic\interop.h
    • <root>\System.Data.SQLite\AssemblyInfo.cs
    • <root>\System.Data.SQLite\SQLite3.cs
    • <root>\System.Data.SQLite\UnsafeNativeMethods.cs
    • <root>\System.Data.SQLite.Linq\AssemblyInfo.cs
    • <root>\test\AssemblyInfo.cs
    • <root>\test\app.config
    • <root>\testce\AssemblyInfo.cs
    • <root>\testlinq\2008\LINQ\App.config
    • <root>\testlinq\2010\EF6\App.config
    • <root>\testlinq\2010\LINQ\App.config
    • <root>\testlinq\2012\EF6\App.config
    • <root>\testlinq\2012\LINQ\App.config
    • <root>\testlinq\2013\EF6\App.config
    • <root>\testlinq\2013\LINQ\App.config
    • <root>\testlinq\2015\EF6\App.config
    • <root>\testlinq\2015\LINQ\App.config
    • <root>\testlinq\2017\EF6\App.config
    • <root>\testlinq\2017\LINQ\App.config
    • <root>\testlinq\Properties\AssemblyInfo.cs
    • <root>\Tests\version.eagle
    • <root>\tools\install\Properties\AssemblyInfo.cs
    You'll need to update the INTEROP_BUILD_NUMBER, INTEROP_LINKER_VERSION, INTEROP_MANIFEST_VERSION, and INTEROP_RC_VERSION properties in the ".vsprops" and ".props" files, and the INTEROP_VERSION define in "interop.h". This version number should track the release versions of the System.Data.SQLite packages (i.e. 1.0.x).

Manual Build

  1. Complete the applicable steps outlined in the All Builds section (above).
  2. Open the appropriate solution for your build platform.
    • The "SQLite.NET.2005.sln" file is the top-level solution primarily designed for use with Visual Studio 2005 in the IDE; however, it may also be used from the command line with MSBuild 2.0.
    • The "SQLite.NET.2008.sln" file is the top-level solution primarily designed for use with Visual Studio 2008 in the IDE; however, it may also be used from the command line with MSBuild 3.5.
    • The "SQLite.NET.2010.sln" file is the top-level solution primarily designed for use with Visual Studio 2010 in the IDE; however, it may also be used from the command line with MSBuild 4.0.
    • The "SQLite.NET.2012.sln" file is the top-level solution primarily designed for use with Visual Studio 2012 in the IDE; however, it may also be used from the command line with MSBuild 4.0.
    • The "SQLite.NET.2013.sln" file is the top-level solution primarily designed for use with Visual Studio 2013 in the IDE; however, it may also be used from the command line with MSBuild 4.0.
    • The "SQLite.NET.2015.sln" file is the top-level solution primarily designed for use with Visual Studio 2015 in the IDE; however, it may also be used from the command line with MSBuild 4.0.
    • The "SQLite.NET.2017.sln" file is the top-level solution primarily designed for use with Visual Studio 2017 in the IDE; however, it may also be used from the command line with MSBuild 15.0.
    • The "SQLite.NET.2005.MSBuild.sln" file is the top-level solution primarily designed for use with MSBuild 2.0 on the command line; however, it may also be used from the Visual Studio 2005 IDE.
    • The "SQLite.NET.2008.MSBuild.sln" file is the top-level solution primarily designed for use with MSBuild 3.5 on the command line; however, it may also be used from the Visual Studio 2008 IDE.
    • The "SQLite.NET.2010.MSBuild.sln" file is the top-level solution primarily designed for use with MSBuild 4.0 on the command line; however, it may also be used from the Visual Studio 2010 IDE.
    • The "SQLite.NET.2012.MSBuild.sln" file is the top-level solution primarily designed for use with MSBuild 4.0 on the command line; however, it may also be used from the Visual Studio 2012 IDE.
    • The "SQLite.NET.2013.MSBuild.sln" file is the top-level solution primarily designed for use with MSBuild 4.0 on the command line; however, it may also be used from the Visual Studio 2013 IDE.
    • The "SQLite.NET.2015.MSBuild.sln" file is the top-level solution primarily designed for use with MSBuild 4.0 on the command line; however, it may also be used from the Visual Studio 2015 IDE.
    • The "SQLite.NET.2017.MSBuild.sln" file is the top-level solution primarily designed for use with MSBuild 15.0 on the command line; however, it may also be used from the Visual Studio 2017 IDE.
  3. Select the desired solution configuration (e.g. ReleaseNativeOnly) and and solution platform (e.g. x64), then "Build->Rebuild Solution". Alternatively, you can select "Build->Batch Build", "Select All", and then "Rebuild".

Automated Build

  1. Complete the applicable steps outlined in the All Builds section (above).
  2. Make sure the "<root>\bin" and "<root>\obj" directories are completely free of all output files. In theory, you should be able to simply delete these directories.
  3. Open a normal command prompt window with "cmd.exe".
  4. Change the current directory to "<root>\Setup".
  5. Enter the following command to build the managed-only binaries:

    CALL build.bat ReleaseManagedOnly

  6. Make sure everything succeeds with no errors; the log file "%TEMP%\System.Data.SQLite.Build_ReleaseManagedOnly_Win32_<year>_Unknown.log" may be checked if any errors should occur.
  7. Enter the following command to build the binaries for Win32 (x86): 

    CALL build.bat ReleaseNativeOnly Win32

    You may need to enter the command "setenv /x86" first if you are using a "Windows SDK Command Prompt" or "Visual Studio Command Prompt" window.
  8. Make sure everything succeeds with no errors; the log file "%TEMP%\System.Data.SQLite.Build_ReleaseNativeOnly_Win32_<year>_Unknown.log" may be checked if any errors should occur.
  9. Enter the following command to build the binaries for x64:

    CALL build.bat ReleaseNativeOnly x64

    You may need to enter the command"setenv /x64" first if you are using a "Windows SDK Command Prompt" or "Visual Studio Command Prompt" window.
  10. Make sure everything succeeds with no errors; the log file "%TEMP%\System.Data.SQLite.Build_ReleaseNativeOnly_x64_<year>_Unknown.log" may be checked if any errors should occur.
  11. Enter the following command to build the setup binaries for all supported build configurations (unfortunately, it is not possible to build the setup using the Inno Setup IDE. It must be done using the provided command line tools due to its highly dynamic nature):

    CALL bake_all.bat

  12. Make sure everything succeeds with no errors. Inno Setup should produce "success" messages very similar to the following:

    Successful compile (X.XXX sec). Resulting Setup program filename is:  abc

Mono Build

  1. Complete the applicable steps outlined in the All Builds section (above).
  2. Make sure the "<root>\bin" and "<root>\obj" directories are completely free of all output files. In theory, you should be able to simply delete these directories.
  3. Open a normal command prompt window with "cmd.exe".
  4. Change the current directory to "<root>\Setup".
  5. Enter the following command to build the managed-only binaries for Mono:

    CALL build_mono.bat

  6. Make sure everything succeeds with no errors; the log file "%TEMP%\System.Data.SQLite.Build_ReleaseManagedOnly_Any CPU_<year>_Unknown.log" may be checked if any errors should occur.

.NET Standard 2.0 Build

  1. Complete the applicable steps outlined in the All Builds section (above).
  2. Make sure the "<root>\bin" and "<root>\obj" directories are completely free of all output files. In theory, you should be able to simply delete these directories.
  3. Open a normal command prompt window with "cmd.exe".
  4. Change the current directory to "<root>\Setup".
  5. Enter the following command to build the managed-only binaries for .NET Standard 2.0:

    CALL build_net_standard_20.bat

  6. Make sure everything succeeds with no errors; the log file "%TEMP%\System.Data.SQLite.Build_ReleaseManagedOnly_Any CPU_NetStandard20_Unknown.log" may be checked if any errors should occur.

.NET Standard 2.1 Build

  1. Complete the applicable steps outlined in the All Builds section (above).
  2. Make sure the "<root>\bin" and "<root>\obj" directories are completely free of all output files. In theory, you should be able to simply delete these directories.
  3. Open a normal command prompt window with "cmd.exe".
  4. Change the current directory to "<root>\Setup".
  5. Enter the following command to build the managed-only binaries for .NET Standard 2.1:

    CALL build_net_standard_21.bat

  6. Make sure everything succeeds with no errors; the log file "%TEMP%\System.Data.SQLite.Build_ReleaseManagedOnly_Any CPU_NetStandard21_Unknown.log" may be checked if any errors should occur.