One of the key differentiators that SQLite for .Net has is that you have full access to the source code and can compile it. Its interesting in the fact most commercial developers like this option, but rarely use it. Kind of a ‘checkbox’ – “if I need to can I?”. This article covers how to get the source code from the archive and compile it up. I find this predominately useful if you are isolating a crash, or trying to determine if there is an option you can ‘flip’ to get an application to behave the way you want to.
The first thing to do is go and grab the latest source! The source code is currently hosted on SourceForge at: http://sourceforge.net/projects/sqlite-dotnet2/. If you go to this page you there are links (or there were at the time of writing!!) to “Download Now!” or “View all files“. If you are looking for the source you need to chose “View all Files”. From here you should choose the latest source package (currently “SQLite-1.0.63.0-source.zip”) and download and unzip to your drive. You should now have the latest and greatest ‘stable’ source code, if you need to pick up an in flight fix or need to most up to date you may have to use CVS to download the package. Unfortunately (albeit fortunate for this article) “SQLite-1.0.63.0-source.zip” contains an issue where the build didnt completely work straight out of the box for Win32 builds. I contacted the team through the developer forum (http://sqlite.phxsoftware.com/forums/) and the problem was resolved in the latest CVS code patch (Patchset 415). So given this we need to pull it from CVS rather than the prepackaged code. NOTE: Normally speaking you should only need (and I would recommend only) the packaged code rather than CVS. Only if you want to live on the bleeding edge, or have a real need to get the latest release should you really use the CVS version. If fact the team doesnt even recommend using the CVS version (http://sqlite.phxsoftware.com/forums/t/1814.aspx).
However to complete the full circle and want to go down the CVS route and you are not familiar with CVS you can find out more information here. Raw CVS executables for Windows can be found here, but I would recommend if you are going to make a habit out of it you get and use TortoiseCVS instead.
cvs -d:pserver:anonymous@sqlite-dotnet2.cvs.sourceforge.net:/cvsroot/sqlite-dotnet2 login
cvs -z3 -d:pserver:anonymous@sqlite-dotnet2.cvs.sourceforge.net:/cvsroot/sqlite-dotnet2 co -P SQLite.NET
[Note if the first line fails create an empty ".cvspass" file and retry it]
Now you should have the latest code straight from the CVS repository, or if you are more sensible 
the packaged ZIP file covered at the beginning of the article.
Now on to the building! In the top level folder there are 2 interesting/key files:
- readme.htm – This details the latest release notes associated with the provider code, and covers the differences between the various historical releases.
- SQLite.NET.sln – This is our well loved and trusted VS2008 solution file!
Starting the solution file the solution loads up and with the latest version I’m using8 projects are loaded:
- SQLite.Interop
- System.Data.SQLite – Compact
- System.Data.SQLite – Managed Only
- System.Data.SQLite – Netmodule
- System.Data.SQLite.Linq
- test
- testce
- testlinq
Out of the box you should be able to build the release and debug files. You will also notice slightly different icons associated with the projects “System.Data.SQLite – Compact” & “testce”. This is because these builds are targeting a mobile or Compact framework device. They dont hurt to be there so feel free to ignore them as they wont be used unless you a compact/mobile build type.
Congratulations you should have successfully built the components and can verify your build by running the “test” application.
Now on to the more technical deep dive of how it works
Firstly lets be clear – this is certainly a non-trivial build process! This is merging C code & .Net code into the same binary DLL using netmodules. More on netmodules can be found at “How to: Build a Multifile Assembly“. Frankly I’m going to just dive into a little more detail here as this concept is key to the build.
Purely looking at the project in Visual Studio is a little misleading:
Hmmm – a “Windows Application” – really…. However looking at the “System.Data.SQLite – netmodule.csproj” in a text viewer you see something very different:
<OutputType>Module</OutputType>
Obviously this is very different than “<OutputType>Library</OutputType>”, “<OutputType>WinExe</OutputType>”, “<OutputType>Exe</OutputType>”. This is the netmodule magic we covered above – all this is largely hidden from the user if they just look at the VS interface. This magic is then referenced through the SQLite.Interop.vcproj though:
<Tool
Name="VCLinkerTool"
AdditionalDependencies="..\System.Data.SQLite\bin\System.Data.SQLite.netmodule"
OutputFile="../bin/System.Data.SQLite.DLL"
ModuleDefinitionFile="src\sqlite3.def"
EmbedManagedResourceFile=""
DelayLoadDLLs="advapi32.dll"
RandomizedBaseAddress="1"
DataExecutionPrevention="0"
ImportLibrary=""
TargetMachine="5"
KeyFile="..\System.Data.SQLite\System.Data.SQLite.snk"
CLRUnmanagedCodeCheck="true"
/>
The good news about this is that this is just a ‘dependency’ and is fully supported in the C/C++ interface in VS2008. A little more can be read about here “.netmodule Files as Linker Input”
Alright so we now have the background knowledge to understand how this build is actually being used. So now lets look at the what the build sets up for us (the below is really the Win32/x64 build):
- Debug
- SQLite.Interop
- System.Data.SQLite – Managed Only
- System.Data.SQLite.Linq
- test
- testlinq
- Debug – Stock
- System.Data.SQLite – Managed Only
- System.Data.SQLite.Linq
- test
- Release
- SQLite.Interop
- System.Data.SQLite – Netmodule
- System.Data.SQLite.Linq
- test
- Release – Stock
- System.Data.SQLite – Managed Only
- System.Data.SQLite.Linq
- test
The project dependencies are:
- SQLite.InterOp -> System.Data.SQLite – netmodule
- System.Data.SQLite.Linq -> SQLite.InterOp
- Test -> SQLite.InterOp
You can see that only the “Release” build doesn’t include the “System.Data.SQLite – Managed Only” version. Any build other than this one generates a build that requires both “System.Data.SQLite” and “SQLite.Interop.DLL”. The “Managed Only” isn’t a pure managed only version of SQLite, it still uses the native SQL C runtime code – but it makes the call out to the Interop dll. The ‘netmodule’ version is used to embed in the ADO.NET C# classes into the ‘System.Data.SQLite’ DLL, all other builds of ‘System.Data.SQLite’ just reference the interop DLL.
Release Build
As mentioned before, in the release build SQLite.Interop is where all the magic happens in this build! This is the one that outputs bin\System.Data.SQLite.DLL (note in all other builds this generates ‘SQLite.Interop.dll’ or in the stock case ‘sqlite3.dll’). However since this is really compiling the standard C SQLite code there is a little more magic going on here. This project has the linker dependency on “..\System.Data.SQLite\bin\System.Data.SQLite.netmodule”. This is how we get the C# ADO.NET provider injected into the System.Data.SQLite.DLL through the netmodules. However this process has the side effect of not being able to debug into the provider 
. So for source code debugging use the debug build that references “Managed Only” rather than the netmodule.
Debug Build
From now on it is fairly standard, although I have seen an odd quirk is that if you attempt to debug into the regular “Debug Build” an error is through regarding the “‘OutputType’ failed”, if you use the “Debug – Stock” build this goes away as the ‘netmodule’ is not included in the build.
Happy compiling and debugging!
Related Links:
