This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 34391 - System.DllNotFoundException: sqlcipher
Summary: System.DllNotFoundException: sqlcipher
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries (show other bugs)
Version: 6.0.99
Hardware: Macintosh Mac OS
: Highest normal
Target Milestone: 6.0 (C6)
Assignee: dean.ellis
Depends on:
Reported: 2015-09-29 10:25 UTC by Andrey Mamontov
Modified: 2015-10-26 01:16 UTC (History)
9 users (show)

See Also:
Is this bug a regression?: ---
Last known good build:

Test case, corrected (36.60 KB, application/zip)
2015-10-09 00:09 UTC, Brendan Zagaeski

Description Andrey Mamontov 2015-09-29 10:25:25 UTC
Issue using Native Libraries

getting System.DllNotFoundException in runtime. Looks like from some time behavior is changed

We are using SqlChipher native lib in our project for long time. We follow you guides (

Shortly about form of project
We have data access layer project with structure like 


Inside .csproj file it look like in form 
    <EmbeddedNativeLibrary Include="libs\armeabi\" />
    <EmbeddedNativeLibrary Include="libs\armeabi-v7a\" />
    <EmbeddedNativeLibrary Include="libs\x86\" />

and dll import looks in form of
        [DllImport("sqlcipher", EntryPoint = "sqlite3_open", CallingConvention = CallingConvention.Cdecl)]
        public static extern Result Open([MarshalAs(UnmanagedType.LPStr)] string filename, out IntPtr db);

We are using this project as dependency inside UI project and the result of build is APK without .do file inside /lib folder.
Comment 1 Andrey Mamontov 2015-09-29 10:35:00 UTC
The last good configuration for our team is:

=== Xamarin Studio ===

Version 5.9.5 (build 10)
Installation UUID: 1b1554ca-6f4f-45dc-ab12-fe2a5b6ae4c3
	Mono 4.0.3 ((detached/d6946b4)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 400030020

=== Xamarin.Android ===

Version: (Enterprise Edition)
Android SDK: /Users/andrey.mamontov/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		4.0.3 (API level 15)
		4.1   (API level 16)
		4.4   (API level 19)
		5.0   (API level 21)
		5.1   (API level 22)
Java SDK: /usr
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)

=== Xamarin Android Player ===

Not Installed

=== Apple Developer Tools ===

Xcode 6.4 (7720)
Build 6E35b

=== Xamarin.iOS ===

Version: (Enterprise Edition)
Hash: 2c66d2f
Branch: master
Build date: 2015-08-04 13:52:25-0400

=== Xamarin.Mac ===

Not Installed

=== Build Information ===

Release ID: 509050010
Git revision: 48d16bc4f12ce3938964fc7c3d72fdc6887ad4ad
Build date: 2015-08-18 16:55:24-04
Xamarin addins: c2d51b360ad9f59e689046d47030df27de28f94a

=== Operating System ===

Mac OS X 10.10.5
Darwin 14.5.0 Darwin Kernel Version 14.5.0
    Wed Jul 29 02:26:53 PDT 2015
    root:xnu-2782.40.9~1/RELEASE_X86_64 x86_64
Comment 2 Jonathan Pryor 2015-09-29 16:17:21 UTC
Please provide the diagnostic build output of a failing build:
Comment 6 Jonathan Pryor 2015-09-30 15:28:03 UTC
The problem is noted in Comment #4:

> The customer noticed that it had something to do with the hierarchy of
> their solution:
> *Create project A (and include .so files here)
> *Create project B (reference project A)
> *Create project C (reference project B)

When "project C" is the Application project, the *expectation* is that all native libraries from all referenced assemblies will be implicitly included into the .apk. This is NOT the case, and is the bug/feature request.

(I'd swear we already had a bug for this, but I can't find it.)

There is a workaround -- modify the Application project so that it also includes the native libraries -- but this is an ugly workaround.
Comment 8 dean.ellis 2015-10-07 11:37:30 UTC
I have replicate this issue working on a fix
Comment 9 dean.ellis 2015-10-08 09:42:48 UTC
Fixed in monodroid/master/b75ed273

Will try to get it into the next release.
Comment 10 Brendan Zagaeski 2015-10-08 23:00:18 UTC
## For bookkeeping, regression status of test case from non-public comment 4: not a recent regression

BAD: Xamarin.Android   (a7ac95b) (Cycle 6 RC0)
BAD: Xamarin.Android   (58099c5) (Cycle 5 SR4)
BAD: Xamarin.Android   (f98871a) (Cycle 5 SR3)
BAD: Xamarin.Android (d23da36) (Cycle 5)
BAD: Xamarin.Android  (86274ad) (Cycle 4 SR4 Hotfix)
Comment 11 Brendan Zagaeski 2015-10-09 00:09:12 UTC
Created attachment 13251 [details]
Test case, corrected

Ah, but the test case from non-public comment 4 appears to be missing a key detail: it is mandatory to force the C# compiler to resolve a type [1] in the "Test" library from within the "BL" library.

Attached is a new "correct" test case that uses the NLua NuGet package to demonstrate the bug.

[1] "In order for the compiler to recognize a type in an assembly, and not in a module, it needs to be forced to resolve the type, which you can do by defining an instance of the type..." (

## "Real" regression status: regression between Cycle 5 SR 3 and Cycle 5 SR 4

BAD:  Xamarin.Android (a7ac95b) (Cycle 6 RC0)
BAD:  Xamarin.Android (58099c5) (Cycle 5 SR4)
GOOD: Xamarin.Android (f98871a) (Cycle 5 SR3)

## Steps to reproduce

Run the attached test case on device or emulator.

## Results

System.DllNotFoundException: lua52

## Expected results

No exception.
Comment 12 Udham Singh 2015-10-09 02:35:42 UTC
I have checked this issue on Xamarin.Android and latest X.Android and getting runtime error 'System.DllNotFoundException: lua52". 
Environment Info:

Please let me know which build has the fix of this issue.
Comment 13 Shruti 2015-10-09 04:20:30 UTC
I have also checked it with latest Master mono-android-6.0.99-66_a801fe81265c24a31a85a81a439864a6d1a27e0e and observe that issue is not fixed with this build. 

Please provide the latest build where the fix of this issue has been merged.

Comment 14 Jatin 2015-10-09 11:51:04 UTC
I have checked this issue with mono-android-6.0.99 84_f46c2337167df8e43d1c48a86d19936329b787be and observed that this issue does not fixed with this build also as shown in screencast :

Hence reopening this issue.

Comment 15 dean.ellis 2015-10-09 12:36:15 UTC
Hmm. Weird I just testing the sample on the same build and it worked. 
Note the NLua only provides libraries for armeabi, armeabi-v7a and x86 so it will NOT work on 64 bit devices which I believe the Nexus 6 is..
Comment 16 Shruti 2015-10-12 03:42:16 UTC
I have checked this issue on Master build mono-android-6.0.99-87_839c5d47d50c0bc08bb3bfa7e248446bf0bb76ea using XAP, Galaxy Note 4 and Nexus 6. It is working fine with master builds.
Environment Info:

But I am observing that this issue still exist on C6 build mono-android-6.0.0-12_ca75e8b4f4bd300c8837c957c0c6cd648df0aaf3
Environment Info:

Note, I will close this issue once get verified on C6 build.
Comment 17 Shruti 2015-10-19 02:43:43 UTC
I have checked this issue on C6 build  mono-android-6.0.0-17_d1232d12dd7bdc5ebc7f8e743003117427fab9d2 using Motorola Nexus 6. Now, attached test case app is getting build and deploy successfully on device.

Environment Info:

Note You need to log in before you can comment on or make changes to this bug.