Home About Eric Topics SourceGear

2014-05-23 12:00:00

First NuGet package for SQLitePCL.raw


I have pushed up the first NuGet package for SQLitePCL.raw.

Is this ready for use on mission-critical applications?


I gave this a version number of "0.1.0-alpha".

By including the -alpha part, I signal to NuGet that this is a pre-release package.

By using 0.1.0 as the version number, I signal to human beings that if you use this package, everything in your life will go wrong. Your dog will leave you for someone else. Your favorite TV show will get canceled. A really dumb VC will send you a term sheet.

This is the first NuGet package, not the last. I gotta start somewhere.

So this package doesn't work at all?

Well, actually, no, it shouldn't be that bad. Underpromise and overdeliver.

I have run my test suite against this package for all of the following environments:

On all the Windows platforms, the tests all pass. For iOS and Android, the only failures are the expected ones.

Why do some of your tests fail on iOS and Android?

Because the version of SQLite which is preinstalled by Apple/Google is a bit old, and some of my tests are explicitly exercising newer SQLite features.

So is this NuGet package ready for testing?

Yes, please.

Eric, I am much smarter than you. Can I give you some constructive feedback?

Yes, please.

Why is the word "basic" in the name of this package?

I think it likely that I may end up with more than one NuGet package for SQLitePCL.raw. Different packages for different use cases. So I need them to have different names.

This one is "basic" in the sense that it tries to be the package that most people will want to use. All of the other contemplated packages would have some sort of less-appealing word in the name, designed to scare people away. The label for the next one might be "broccoli".

The main tradeoff is the issue of where your app is getting SQLite itself. For [much] more detail on this, see my recent blog entry on The Multiple SQLite Problem.

Anyway, for this "basic" package, the iOS and Android assemblies use the SQLite library which is part of the mobile OS, and all of the Windows assemblies bundle a sqlite3.dll.

Which version of SQLite is bundled on the Windows platforms?

How was the bundled SQLite library compiled?


Can I rely on all future versions of this package having the SQLite library compiled with exactly those options?


How do I find this package?

Direct link: https://www.nuget.org/packages/SQLitePCL.raw_basic

And, it comes up for me if I just search for "SQLitePCL" on NuGet.

Hey, there are TWO results of that search? What's the deal?

Mine is the one called SQLitePCL.raw. The other one is by MSOpenTech.

And actually, my work is a [hopefully friendly] fork of theirs. Thanks to those folks (whoever they are) for a solid starting point. I am available to collaborate with them if there is interest.

Why did you fork the other one?

See the README on GitHub for some info on this.

Any caveats when trying to use this on iOS?

AFAIK, no. For me, this Just Works.

Any caveats when trying to use this on Android?

AFAIK, no. For me, this Just Works.

Any caveats when trying to use this on .NET 4.5?

You need to compile for a specific CPU (x86, x64), not "Any CPU". In Visual Studio, right-click on your solution and choose Configuration Manager.

Any caveats when trying to use this on Windows Phone 8.0?

Not really. Just make sure you are building for x86 for the emulator or ARM for an actual device. In Visual Studio, right-click on your solution and choose Configuration Manager.

Any caveats when trying to use this on Windows RT or Windows Phone 8.1?

Two issues:

What other forms of this package are you planning?

I'm considering one that doesn't bundle any SQLite instances at all. For use with cases where somebody wants to have their own build of SQLite. Or for people who want to use the SQLite vsix SDK builds on visualstudiogallery.msdn.microsoft.com.

Why are some of the platform assemblies in the build directory instead of the lib directory?

Android and iOS are in lib.

All the Windowsy ones are in build, because they're all CPU-specific, so they need more help than lib can provide. An MSBuild .targets file is used to inject the appropriate reference.