Bugzilla – Bug 2148
Last modified: 2014-06-24 23:16:18 EDT
When trying to use Mono.Data.Sqlite v220.127.116.11 from .net on windows I get the
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)
SqliteConnectionHandle implements CriticalHandle which has the following
[SecurityPermissionAttribute(SecurityAction.InheritanceDemand, UnmanagedCode =
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 v18.104.22.168 cannot be used on
.net until a fix is made (adding the SecurityPermissionAttribute).
Mono.Data.Sqlite uses a assembly level security permission.
[assembly: SecurityPermission(SecurityAction.RequestMinimum, SkipVerification =
RequestMinimum is obsolete in .net 4.0 this may explain why it stopped working
with .net 4.0
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?
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.
The following patch works around the issue by using the old security rules:
@@ -35,9 +35,13 @@
[assembly: ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]
-[assembly: SecurityPermission(SecurityAction.RequestMinimum, SkipVerification
+ #if NET_4_0
+ [assembly: SecurityRules(SecurityRuleSet.Level1)]
+ [assembly: SecurityPermission(SecurityAction.RequestMinimum,
SkipVerification = true)]
// 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.
Are there any plans to address this?
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,
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.
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,
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!
you must add that statement to the Mono.Data.Sqlite AssemblyInfo.cs, and not
so I would have to recompile (at least portions of) SQLite?
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.
This would be great (since I have to admit that I have no idea how to recompile
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
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.
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".
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.
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*
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)
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.