This blog post was authored by Himadri Sarkar, a program manager on the Windows Phone team.
You may have heard that with the Windows Phone SDK 8.0 release, the SQLite database engine is fully supported on the Windows Phone platform. Many thanks to the SQLite team for making the SQLite engine for Windows Phone available as a Visual Studio extension. In this post, I would like to show you how you can use the SQLite database engine from your Windows Phone 8 project.
The first step is to install the Visual Studio extension package, which contains all the required pieces.
To start with a sample app, create a blank Windows Phone App project and name it SQLiteSampleApp.
Let’s add the support for SQLite database to this app.
Because the SQLite engine is a native component, using it in a Windows Phone 8 managed app requires the APIs to be wrapped in a Windows Phone Runtime component that can be called from the managed layer.
There is already a “Windows 8” Runtime component available in github for this purpose, and there is a NuGet package that you can use in your project to get this component. This sqlite-net wrapper offers a bunch of synchronous as well as asynchronous methods for easy usage of SQLite. However the sqlite-net wrapper does not have support for the native SQLite Windows Phone 8 extension that we downloaded from the Visual Studio Gallery earlier. Instead, it relies on an open-source implementation of SQLite called csharp-sqlite.To use the sqlite-net wrapper, we use a fork created by Peter Huene that allows use of the native SQLite Windows Phone 8 extension. This fork has recently been pulled into the sqlite-net master branch, and the latest NuGet package (1.0.7 at the time of writing) also reflects this update.
There are a few things we need to get done to get this all working. The following section explain how.
Start by adding the sqlite-net package (1.0.7) to the Windows Phone app project using the following steps.
Download and add the sqlite-net-wp8 native C++ project to the solution. This is the wrapper project that will replace the csharp-sqlite functionality. At this time, there’s no NuGet package available for sqlite-net-wp8, so we need to download and add it to our project manually. Use the following steps to download and add the project:
Additionally, to indicate to sqlite-net that we want to use the sqlite-net-wp8 project added in earlier steps, we need to add a compiler directive to the Windows Phone app project:
After you have set up everything, you can test the SQLite database functionality by using the sample code referred to in the GitHub wiki. The information in this link is about Windows Store apps, but it should be helpful for Windows Phone apps after you have completed the steps in this post.
Can someone help me understand why do we need to go trough these steps every time we want to use sqlite in a project?
Is it really not possible to generate wrapper library and use it across multiple different projects?
Or is the process tied to each project separately?
Is this considered good development experience from Microsoft these days? This is so sad I don't even know where to start and the only reason we have a .NET wrapper at all is some helpful third party dev.
just a quick tip, the current version of the sqlite for windows phone extension is 3.7.16 and the sqlite-net-wp8 code uses sqlite 220.127.116.11 so you cannot add the c++ project file to your solution unless you have the older sqlite for windows phone extension version 18.104.22.168.
If you can wait until there is a nuget package I am sure it will be much easier to use and stay updated with sqlite for windows phone 8.
Here is a database compatible with Windows 8:
Why so I need some wrappers? I thought WP8 has WinRT. For me "sqllite supported on wp8" means that it uses winrt. Why do I need winrt, if I still have to invoke the native code.
Still thinking winrt is a marketing gag to kill .net :(
As the author of sqlite-net, I just want to make one clarification - it works out of the box with the native driver (it even includes the native drivers in the repo). But you do have to make those #defines. We are working on a nuget package that will simplify all of this.