I can't build a native SQLite .so for all flavors of *nix and OSX and include it in my package -- its just beyond the scope of what I'm trying to do. For Windows, .NET supports me merging the managed and unmanaged code into a single mixed-mode assembly. Mono doesn't support this at all, so I have to provide a managed-only version that supports dynamic linking.
Unfortunately there's just a certain level of underlying API support required by the provider -- and lacking that support, certain functionality is bound to be missing. The trick is attempting to fail gracefully if that API call doesn't exist. This is rather difficult when .NET is doing the binding behind the scenes. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of W Allan Edwards Sent: Tuesday, February 10, 2009 6:36 PM To: [email protected] Subject: Re: [sqlite] SPAM: Re: Question on missing Entry Point for Sqlite 3 Just food for thought. In that case, your group (assuming you are the sqlite ADO.NET guy) appears to ship an all inclusive build of sqlite in the adapter, but then the fully managed only libs that dynamically link of to the platform compiled binaries for sqlite? Why not include within the shipped build the binaries compiled properly to allow your ado.net stuff to work properly. Developers would be able to know for SURE that they have the right binaries for both Linux and windows. >From a developer "usability" standpoint, having the target binaries for all platforms in your install would be really nice. So this is just a humble request. We then just have to copy the right libs into our installer and all will be happy.> From: [email protected]> To: [email protected]> Date: Tue, 10 Feb 2009 18:21:39 -0700> Subject: Re: [sqlite] SPAM: Re: Question on missing Entry Point for Sqlite 3> > I can try and make my System.Data.SQLite provider fail gracefully if this> API function doesn't exist -- but it may not be an error I can catch easily.> .NET tends to link these calls when the class is referenced, and it happens> in a place at runtime that I don't think I can put try/catch blocks around.> > Also, a lot of ADO.NET functionality will not be available if this> preprocessor symbol is missing, and Entity Framework stuff will definitely> not work properly.> > > -----Original Message-----> From: [email protected]> [mailto:[email protected]] On Behalf Of W Allan Edwards> Sent: Tuesday, February 10, 2009 5:00 PM> To: [email protected]> Subject: SPAM: Re: [sqlite] Question on missing Entry Point for Sqlite 3> > > I have emailed Miguel of Mono directly, the mono contact form, and the> ado.net provider guys. I have not heard anything back from anbody but this> almighty sqlite group.> > Whether the doctor turns this code off by default or not I would hope> somebody makes the provider behavior the same cross platform. : - )> > You guys are awesome at support. Thanks again for exploration of this issue> with me.> > Allan> Date: Mon, 9 Feb 2009 14:17:30 -0800> From: [email protected]>> To: [email protected]> Subject: Re: [sqlite] Question on missing Entry> Point for Sqlite 3> > -----BEGIN PGP SIGNED MESSAGE-----> Hash: SHA1> > D.> Richard Hipp wrote:> > These two factors are sufficient to convince me to> leave it turned off > > by default.> > You are aware that last year you> turned it on by default for the> libraries you build :-)> >> http://www.sqlite.org/cvstrac/chngview?cn=5539> > I'd guess that this whole> issue arose because the .net wrapper people> used the Windows SQLite DLL> from sqlite.org and only tested on Windows> so they didn't realise the> symbols were optional and not on by default> by anyone compiling using> ./configure such as Mac and Linux folk.> > Roger> -----BEGIN PGP> SIGNATURE-----> Version: GnuPG v1.4.9 (GNU/Linux)> >> iEYEARECAAYFAkmQq3YACgkQmOOfHg372QSfSgCgnxTy7YkajElmuwRYM783e/Ci>> u6YAn0HFYiyYNd9MWXV+MovZkBP1jlXg> =K8D6> -----END PGP SIGNATURE----->> _______________________________________________> sqlite-users mailing list>> [email protected]>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users> _______________________________________________> sqlite-users mailing list> [email protected]> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users> > > _______________________________________________> sqlite-users mailing list> [email protected]> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
