Issue running standalone using SQLite

We're working on a game that needs access to a SQLite .db file. We can't use PlayerPrefs so we're sticking with the SQLite solution. The problem that we are running into is that it works in the editor but we get the following debug crash when we try to load the .db in a stand alone player.

ArgumentOutOfRangeException: Argument is out of range. Parameter name: options at System.Text.RegularExpressions.Regex.validate_options (RegexOptions options) [0x00000] in :0 at System.Text.RegularExpressions.Regex..ctor (System.String pattern, RegexOptions options) [0x00000] in :0 at DbLinq.Vendor.Implementation.SqlProvider..cctor () [0x00000] in :0 Rethrow as TypeInitializationException: An exception was thrown by the type initializer for DbLinq.Vendor.Implementation.SqlProvider at DbLinq.Sqlite.SqliteSqlProvider..ctor () [0x00000] in :0 at DbLinq.Sqlite.SqliteVendor..ctor () [0x00000] in :0 at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (object,object[],System.Exception&) at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in :0 Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation. at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in :0 at System.Reflection.MonoCMethod.Invoke (BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in :0 at System.Reflection.ConstructorInfo.Invoke (System.Object[] parameters) [0x00000] in :0 at System.Activator.CreateInstance (System.Type type, Boolean nonPublic) [0x00000] in :0 at System.Activator.CreateInstance (System.Type type) [0x00000] in :0 at DbLinq.Data.Linq.DataContext.GetVendor (System.String& connectionString) [0x00000] in :0 at DbLinq.Data.Linq.DataContext..ctor (System.String connectionString) [0x00000] in :0 at ContentManager.LoadDatabase (System.String sFileName, System.String sGameID, System.String sEnableFlags, System.String sDisableFlags) [0x00000] in :0 at BoardAttributes.Start () [0x00000] in :0

Our LoadDatabase function takes a string and we're passing it: ContentMan.LoadDatabase(@"C:\Content\2010\GameContent.db");

Our ContentMan then attempts to load the .db using the following code

    Table<ContentFilesTable> FilesTable;
    Table<FileTagsTable> TagsTable;
    SQLiteConnectionStringBuilder csb = new SQLiteConnectionStringBuilder();
    csb.Add("data source", sFileName);
    csb.Add("DbLinqProvider", "sqlite");
    SQLiteConnection connection = new SQLiteConnection(csb.ConnectionString);
    DataBase = new DataContext(connection);
    FilesTable = DataBase.GetTable<ContentFilesTable>();
    TagsTable = DataBase.GetTable<FileTagsTable>();
    //Grab the indexs with only the gameID we want
    var query = from n in TagsTable where n.tags.Contains("test") == true select n;
    List<FileTagsTable> MyList = query.ToList();

We're at a loss of why this successfully works in the editor and not at runtime, we're only basically just shotgunning ideas on how to fix it so any and all suggestions are welcome. Thanks!

That is 100% managed code, full SQLite3 support, all platforms.
No native dependencies.

Just trying to make head or tails of the error -- it's coming from the DataContext constructor, in a call to GetVendor.

Turns out source code for DataContext.cs is available online. It uses the vendor info in the connection string (or defaults in your case) to determine which assembly to load and what class to load from the assembly.

It appears the default assembly is DbLinq.SqlServer.dll -- perhaps this Dll is missing from your standalone build? I'd review all the SQLite assemblies you're using and make sure they are all available in the standalone build.

So with just guessing and trying we came up with what the issue was. Turns out our problem was the player setting Api Compatibility Level being set to .NET 2.0 subset. A change to just .NET 2.0 resolved this issue.