Build Problems with SQLite-WinRT Wrapper

Question

I am having trouble getting my app to build for ARM target after adding the SQLite-WinRT database wrapper. I could reproduce this with a simple test app as follows:

(This is done in Visual Studio 2013.)

1. Create an empty Windows 8.1 universal app (WinRT)
2. Download SQLite for Windows Phone 8.1 and SQLite for Windows Runtime (Windows 8.1) using Tools/Extensions and Updates. Add them to the respective projects' references.
3. Using NuGet, add SQLite-WinRT package to each project.
4. Build for x86 (local machine or phone emulator) -> no problems.
5. Build for ARM (phone device) -> build error shown below (independent of debug or release builds).

There was a mismatch between the processor architecture of the project being built "ARM" and the processor architecture, "x86", of the implementation file "C:\Users\jr\Documents\Visual Studio 2015\Projects\sqlite-test\packages\Sqlite-Winrt.3.8.7.1\lib\wpa81\SQLiteWinRT.dll" for "C:\Users\jr\Documents\Visual Studio 2015\Projects\sqlite-test\packages\Sqlite-Winrt.3.8.7.1\lib\wpa81\SQLiteWinRT.winmd". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and implementation file, or choose a winmd file with an implementation file that has a processor architecture which matches the targeted processor architecture of your project.

I posted a small test project here (Windows Phone 8.1 empty project, added SQLite, added SQLite-WinRT via NuGet).

Haemoid

try this. Go to your Bulid Configuration Manager and set Plateform for your windows and windows phon to ARM. – Overcloud

Thank you but that was not it. When I said "Build for ARM" I actually meant the platform target set to ARM. – Haemoid

Same thing happed to me. some how my project's build settings target plateform was set to Any CPU that cased this issue even though my build setting was ARM – Overcloud

I'll +1 your answer as it is a valid solution in similar scenarios with same symptoms. Unfortunately it does not solve my issue, so I leave it open. – Haemoid

@MuhammadSaifullah I created a small test project (see link above). if you can spot a configuration error that I overlooked, misunderstood, ... please point it out and the bounty is yours. – Haemoid

You need to remove SQLite for winrt – Overcloud

I have updated my answer. If you still have the problem let me know. – Overcloud

Answer 1

One workaround for the problems with the NuGet package is adding the sqlite-winrt sources to your phone or universal app.

1. install SQLite for Windows Phone 8.1 (and for universal also Windows Runtime (Windows 8.1)) in Tools -> Extensions and Updates if not done already
2. add references to the respective projects
3. download the sources for the sqlite-winrt wrapper
4. copy the SQLiteWinRTPhone81(RT) (and SQLiteWinRT81 if needed) folders to your solution
5. add the projects to your solution in Visual Studio (right-click on solution -> Add -> Existing Project)
6. add references to the respective projects
7. edit the references for the sqlite-winrt project(s) to point to the correct version of SQLite (right-click project -> Properties -> Common Porperties -> References): add a reference to the current SQLite version in your project and remove the old reference
8. build your solution

Haemoid

Answer 2

Go to project properties open build tab and set target platform to ARM

Edit You have added WinRt sqlite. it is buid on x86 and when you want to build it on ARM process Architecture it cannot build you need to remove WinRTSQlite dll than your project will work fine. Here is Code

Hope this helps

Overcloud

Thank you. But as already discussed under frenk91's answer, eliminating the subject of the question is not a solution. According to the project page at sqlwinrt.codeplex.com Windows phone and hence ARM targets should be supported by that NuGet package. I fully agree: I seem to be doing something wrong, but what is it? – Haemoid

This answer earned two 'useful' votes in an earlier version. The current one is not meaningful. – Haemoid

Answer 3

I have downloaded your project and on the references i have found that you are using SQLite-WinRT and sqlite for windows phone 8.1, you don't need both.

as soon as you remove SQLite-WinRT your project start compiling.

EDIT:

inside a universal app you have to add only the right references, if is a phone project just add sqlite for windows phone 8.1, instead on the windows 8.1 app add only the SQLite-WinRT

Copperhead

SQLiteWinRT is the database wrapper. If I remove that I have to write my own, and I don't feel confident enough for that. – Haemoid

you don't need a wrapper, just add this nuget package nuget.org/packages/sqlite-net/1.0.8 – Copperhead

That would be another wrapper, and a feasible alternative. I have found that sqlite-winrt is more suitable for my purposes. – Haemoid

there is no way to use sqlite-winrt because doesn't contain a version for ARM. I have used sqlite-net on any of my project, you can find the documentation on github github.com/praeclarum/sqlite-net. – Copperhead

To be more specific on my choice (I am actually using sqlite.net at the moment): I am using data types in my app that are not supported by sqite.net. In order to convert them into types supported in SQLite, I need to modify sqlite.net, which causes new problems. Also, thinking aobut coding for differnt platforms and maintainability, there is nothing similar to sqlite.net for Android and iOS. – Haemoid

if you are writing a cross platform app using C# as a language sqlite-net is perfect, because support multiple platform. but the problem of having your type not supported still remain, maybe you can serialize it and then save this type on the db – Copperhead

Well, the thing is, most if not all sources I found in fact claim that sqlite-winrt supports windows phone. – Haemoid

Let us continue this discussion in chat. – Haemoid

OK, learned my lesson from this one. There is no correct answer so far. Both suggest to remove the module in question, which is not a solution. Now the question was just upvoted another 5 times today, so others seem to have the same problem and deleting it would not be nice. The bounty will be auto-awarded to a wrong answer unless I do it. So I decided to give it to this answer because the discussion at least points out alternatives and the question was eventually understood. The answer is wrong nevertheless. I have posted a workaround. – Haemoid