Bug 2148 - Mono.Data.Sqlite.dll TypeLoadException
Summary: Mono.Data.Sqlite.dll TypeLoadException
Alias: None
Product: Class Libraries
Classification: Mono
Component: Mono.Data.Sqlite ()
Version: 2.10.x
Hardware: PC Windows
: High normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2011-11-22 00:12 UTC by Daniel Hughes
Modified: 2014-06-24 23:16 UTC (History)
12 users (show)

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

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Daniel Hughes 2011-11-22 00:12:51 UTC
When trying to use Mono.Data.Sqlite v4.0.0.0 from .net on windows I get the following exception

Unhandled Exception: System.TypeLoadException: Inheritance security rules violated by type: 'Mono.Data.Sqlite.SqliteConnectionHandle'. Derived types must either match the security accessibility of the base type or be less accessible.
   at Mono.Data.Sqlite.SQLite3.Open(String strFilename, SQLiteOpenFlagsEnum flags, Int32 maxPoolSize, Boolean usePool)
   at Mono.Data.Sqlite.SqliteConnection.Open()

SqliteConnectionHandle implements CriticalHandle which has the following attribute:

[SecurityPermissionAttribute(SecurityAction.InheritanceDemand, UnmanagedCode = true)]

This requires that the inheriting class (SqliteConnectionHandle) have the same or more restrictive permissions. However SqliteConnectionHandle does not specify any security permissions and so violates the contract.

This does not seem to be a problem when running on mono for linux only .net for windows. (maybe mono does not implement these security checks)

The upshot of all this is that Mono.Data.Sqlite.dll v4.0.0.0 cannot be used on .net until a fix is made (adding the SecurityPermissionAttribute).
Comment 1 Daniel Hughes 2011-11-28 02:23:25 UTC
Mono.Data.Sqlite uses a assembly level security permission.

[assembly: SecurityPermission(SecurityAction.RequestMinimum, SkipVerification = true)]

RequestMinimum is obsolete in .net 4.0 this may explain why it stopped working with .net 4.0
Comment 2 Francois 2012-01-24 15:24:05 UTC

I have the exact same problem and am currently unable to run my application using the .net 4.0 version of the Mono.Data.Sqlite assembly. 

How do I fix this?

Comment 3 Joe 2012-02-19 17:46:33 UTC
Adding [SecuritySafeCritical] and [SecurityCritical] attributes to various classes and methods gets my simple test program working again. They can't be specified on the assembly level. I hope there's a better solution.
Comment 4 Joe 2012-03-03 13:27:46 UTC
The following patch works around the issue by using the old security rules:

@@ -35,9 +35,13 @@
 [assembly: AllowPartiallyTrustedCallers]
 [assembly: ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]
-[assembly: SecurityPermission(SecurityAction.RequestMinimum, SkipVerification = true)]
+  #if NET_4_0
+    [assembly: SecurityRules(SecurityRuleSet.Level1)]
+  #else
+    [assembly: SecurityPermission(SecurityAction.RequestMinimum, SkipVerification = true)]
+  #endif
 // Version information for an assembly consists of the following four values:
 //      Major Version


Hopefully it applies, as I am using Mercurial. I don't have a full clone of the repo handy, so I couldn't do a pull request.

TL;DR: Add [assembly: SecurityRules(SecurityRuleSet.Level1)] for .NET4.
Comment 5 stijn.herreman 2012-05-27 13:23:17 UTC
Are there any plans to address this?
Comment 6 Muyyed 2012-08-09 15:29:34 UTC
Hi Joe,

As I am new to Mono world. I would really appreciate if you can elaborate more or guide on to how to apply the mentioned Patch.

I am using Mono for Mac.

Thanks in advance,
Comment 7 Joe 2012-08-09 19:31:09 UTC

this should not apply to you since you're on Mac. But if you're on Windows, all you need to add, since you're on .NET4, is [assembly: SecurityRules(SecurityRuleSet.Level1)], probably in the AssemblyInfo.cs, and you should be all set.

The patch was posted in case someone wanted to patch the official source tree to compile it for .NET4, 3.5, etc.
Comment 8 Muyyed 2012-08-10 08:00:56 UTC
Hi Joe,

Thanks a lot for your prompt response.

It is true that I don't have any problem in Mac. 

However, when I port my app to Windows the app will crash when coming to the following statement  in my code 

SqliteConnection dbcon = new SqliteConnection(conString);.

Thanks in advance,
Comment 9 DBa 2012-08-12 08:07:00 UTC
Hi Joe,

my (small) application does not have an AssembyInfo.cs. It is normally compiled with Mono on Linux (and runs perfectly there), but has now to be deployed to Windos, too - which fails with this exception when encountering SqliteConnection.Open() call. Could you point me to a right direction about where to put that "[assembly:...]" statement? Putting it just before the definition of my main application class did not help...

Thanks in advance!
Best regards
Comment 10 Joe 2012-08-12 15:56:29 UTC

you must add that statement to the Mono.Data.Sqlite AssemblyInfo.cs, and not your application.
Comment 11 DBa 2012-08-12 15:57:59 UTC

so I would have to recompile (at least portions of) SQLite?
Comment 12 stijn.herreman 2012-08-12 16:02:02 UTC

that's correct. I've been meaning to do a recompile for a while, just need to get an environment set up.
If I get to it before you attempt it yourself, I'll share the binaries.
Comment 13 DBa 2012-08-17 05:40:09 UTC
This would be great (since I have to admit that I have no idea how to recompile Mono.Data.SQLite)
Comment 14 DBa 2012-08-23 14:41:16 UTC
I have recompiled Mono 2.11.3 from tarball (I know that this bug is for 2.10.x but it is not fixed in 2.11.3 yet...), so here is the DLL:


(I have just applied the above patch to ./mcs/class/Mono.Data.Sqlite/Assembly/AssemblyInfo.cs)
Comment 15 stijn.herreman 2012-08-23 14:59:42 UTC
Thanks a lot, DBa. Could you say how you compiled?
I've tried cross-compiling on Linux and compiling with Visual Studio but got stuck with both.
Comment 16 DBa 2012-08-23 15:06:07 UTC
This was really straight-forward:

- Downloaded the most recent tarball to a Debian system
- ./configure --prefix=/opt/mono-2.11 && make 
- After this verified that the compile works okay, patched the AssemblyInfo.cs, and done a "make && sudo make install".
Comment 17 stijn.herreman 2012-08-23 15:11:56 UTC
So MinGW isn't needed? I was trying to follow along with http://www.mono-project.com/Cross-compiling_Mono_for_Windows but kept getting error messages about not being able to compile at all.
I'll give it a shot later tonight, thanks.
Comment 18 DBa 2012-08-23 15:23:46 UTC
I did not need the complete Mono for Windows, only the SQLite part, since the rest is provided with the .NET 4.0 framework (I'm developing and compiling and running the application on Linux, but wanted to be able to "outsource" computing work to Windows PCs since the application is a massive A* implementation).
Comment 19 Jeffrey Stedfast 2013-11-23 15:58:32 UTC
I just ran into this issue myself and have confirmed that Joe's fix works.

Applied and committed to git master, will hopefully show up in Mono 3.2.7 (3.2.6 seems to have been branched already)
Comment 20 firefly2442 2014-06-24 23:16:18 UTC
I ran into this problem with the current 3.2.3 Windows stable build.  Downloading the archive of 3.4 and building it on Linux as another user above mentioned and then copying over the resulting DLL file fixed the issue.  So I believe it is fixed in 3.4 going forward.