Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
When trying to use Mono.Data.Sqlite v220.127.116.11 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)
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 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 = true)]
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 = true)]
+ #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 your application.
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 Mono.Data.SQLite)
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)
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* implementation).
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.