Microsoft.Data.Sqlite for WinRT
What is it?
This repository contains ASP.NET implementation of
Microsoft.Data.Sqlite modified to support WinRT for Windows 8.1 and Windows Phone 8.1.
Microsoft.Data.Sqlite rely on
System.Data.Common, which does not exist in WinRT for Windows 8.1 and Windows Phone 8.1, this repository also contains
.NET Core implementation of
System.Data.Common modified to support WinRT for Windows 8.1 and Windows Phone 8.1.
The result is
System.Data.Common libraries that achieve 100% feature parity with the ones from original repositories:
Microsoft.Data.Sqlite: commit 58195cb10236f22c14a6cef2e7e80ccf1b0e2462.
System.Data.Common: commit 714c3d65b723a267c30f5b820fb651fe6ea30cac.
Still, see "How?" and "Pitfalls and Known Issues" sections to see if there is any limitation and unsupported feature.
Why it is needed?
It came out of a personal need. I was developing a Windows 8.1 Universal app and wanted some sort of database-like storage. Instead of reinventing the wheel, I looked around for proven-to-be-working solutions.
Most of the roads eventually let to SQLite and its WinRT support for Windows 8.1 and Windows Phone 8.1. However, neither Microsoft nor SQLite.org has a .NET wrapper for the native APIs for my targeted platforms.
The natural fallback is 3rd party and community libraries. The ones I came across have one or more of the following:
- Missing some features that I wanted.
- Cannot be used in a portable library that targets WinRT.
- Require some learning curve due to the way their APIs are written.
- Not updated for years; hence their compatibility with the latest SQLite library is unknown.
Hence, "plan C" was to port the library that I have some familiarity with, which is
Microsoft.Data.Sqlite, and its dependencies.
How it was done?
It was mostly manual work:
- Created a Visual Studio solution with 2 Portable Class Library projects, targeting Windows 8.1 and Windows Phone 8.1. The projects are named
- Copied the files from .Net Core
System.Data.Commonrepository, and its referenced files, and placed them in
System.Data.Commonprojects; where a folder represents a
- Copied the files from ASP.NET
Microsoft.Data.Sqliterepository and placed them in
Microsoft.Data.Sqliteprojects; where a folder represents a
NativeMethodsImpl.ttfile. Note: Although
winsqlite3.dllis not available and not used in WinRT for Windows 8.1 and Windows Phone 8.1 apps, Windows App Certification Kit generates "API not supported errors" that may prevent approving the app.
- Compiled the code and see what the compiler is complaining about.
- Replace the code that is not supported in WinRT for Windows 8.1 and Windows Phone 8.1 with the equivalent alternative; e.g,
Debug.Fail("Message")was replaced by
- Removed the code that is not supported at all in WinRT for Windows 8.1 and Windows Phone 8.1; e.g.,
Environment.GetEnvironmentVariable("EnvVariable")(you cannot read or write Environment variables in WinRT).
- Compiled again. If the compiler is still complaining, go to #5, otherwise got to #8.
How to get it?
Execute the following command in Package Manager Console:
Or search for
Microsoft.Data.Sqlite.WinRT in NuGet Package Manager.
Pitfalls and Known Issues
None of these pitfalls and known issues are known to cause this library to "misbehave":
- As stated in "How it was done?" section, this is a manual work and similar work needs to be done to maintain the library.
- There are several places in the code where Preprocessor Directives, such as
#if !NET451, are used. Because
NET451is not defined, the code which is not for
NET451is the one that is eventually compiled. I have not reviewed or tested all these Directives to see their behaviour in WinRT for Windows 8.1 and Windows Phone 8.1.
- ASP.NET team uses some version of
ResXFileCodeGeneratorthat generates methods with parameters from
*.resxfiles. I don not have this version and do not know how to get it (if someone knows, I appreciate a help). Hence, every time the resources are regenerated, I have to revert the generated file to the pre-generated file I took from the original repository, and if anything is added, I will add it manually.
- Because the code that uses
winsqlite3.dllwas removed (see "How it was done?" section), calling
SqliteEngine.UseWinSqlite3()will fall back to using
sqlite3.dllthat is shipped with the app. This should not be an issue. I am unaware of any case where someone might need to use
winsqlite3.dllwith a library that targets WinRT for Windows 8.1 and Windows Phone 8.1, or if this will even work.
What about the future?
Nothing fancy and there are no big plans awaits this work; yet, it is not abandoned.
Here are couple of ideas that might come in some point in the future:
Look at the original repositories for any update and reflect the changes on this repository.
Add the test projects from the original repositories.
Keep maintaining the version number with the original libraries; Major and Minor, not Build and Revision.
Merge the changes with the original repositories.
System.Data.Commonsupport .NETStandard 1.2, which means supporting WinRT for Windows 8.1 and Windows Phone 8.1. But,
Microsoft.Data.Sqliteonly supports .NETStandard 1.3 because it reads Environment Variables. There are 2 things need to happen before the merge, (1) finding a way to get Environment Variables in .NETStandard 1.2, and (2) finishing MSBuild changes that allow using .NETStandard libraries in none-.Net Core projects.
System.Data.Commoninto different NuGet packages. I will do this only if (1)
System.Data.Commonproven to be useful by itself, and (2) the previous point is not done.
Both the codes maintain their original license:
Microsoft.Data.Sqlite: Apache License, Version 2.0
System.Data.Common: The MIT License (MIT)
I have not changed the original code in any way that modifies its function; hence, all the credits and the copyrights go wherever they go in the original repositories.
My thanks go to the teams behind .NET Core and ASP.NET, the people behind open-sourcing .NET and related libraries, and the people who contributed to the original repositories. Without there work, this repository would not be possible; at least, not without considerable effort.
It is a success story. My success criteria is that I was able to use this work in my project.
I put this work here and on NuGet.org because it was useful for me. I hope that someone other than myself will find it useful for them.