Re: [sqlite] ADO.NET Provider, targeting any cpu
Damien wrote: > > It is working for a classic application. But for a website (or a web > application), the directories x86 and x64 should be in the "~/Bin" > directory or in "~/" ? > The "x86" and "x64" directories should be just inside the directory where the "System.Data.SQLite.dll" file is located. -- Joe Mistachkin ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] ADO.NET Provider, targeting any cpu
Hi, It is working for a classic application. But for a website (or a web application), the directories x86 and x64 should be in the "~/Bin" directory or in "~/" ? Thanks. Damien 2012/5/23 Joe Mistachkin > > Rob Richardson wrote: > > > > This is the first I have heard of this feature or requirement or whatever > this is. > > This statement seems to be saying that the "System.Data.SQLite > managed-only assembly" > > is different from the "System.Data.SQLite assembly". Is that true? When > I download > > a new version of the System.Data.SQLite installation package, how will I > tell the > > difference between the two? > > > > The download page for System.Data.SQLite refers to packages that contain > one > of the two > kinds of System.Data.SQLite assemblies: > > 1. The "managed-only assembly", which contains only managed (CLR) code and > uses the > SQLite.Interop.dll native library. > > 2. The "mixed-mode assembly", which contains native (x86 -OR- x64) and > managed (CLR) > code. This assembly does not use the SQLite.Interop.dll native library > because all > that code is built into the mixed-mode assembly itself. > > The FAQ also contains some useful information on mixed-mode assemblies: > >https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki > > -- > Joe Mistachkin > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] ADO.NET Provider, targeting any cpu
Rob Richardson wrote: > > This is the first I have heard of this feature or requirement or whatever this is. > This statement seems to be saying that the "System.Data.SQLite managed-only assembly" > is different from the "System.Data.SQLite assembly". Is that true? When I download > a new version of the System.Data.SQLite installation package, how will I tell the > difference between the two? > The download page for System.Data.SQLite refers to packages that contain one of the two kinds of System.Data.SQLite assemblies: 1. The "managed-only assembly", which contains only managed (CLR) code and uses the SQLite.Interop.dll native library. 2. The "mixed-mode assembly", which contains native (x86 -OR- x64) and managed (CLR) code. This assembly does not use the SQLite.Interop.dll native library because all that code is built into the mixed-mode assembly itself. The FAQ also contains some useful information on mixed-mode assemblies: https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki -- Joe Mistachkin ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] ADO.NET Provider, targeting any cpu
-Original Message- The System.Data.SQLite managed-only assembly, when the native library pre-loading code is enabled (which it is by default starting with release 1.0.80.0), will now attempt to detect the processor architecture of the process it is being loaded into and then it will attempt to load the native interop library from an appropriately named subdirectory (e.g. "x86", "x64", etc). In order to take advantage of this feature, the System.Data.SQLite managed-only assembly should be deployed with the other managed binaries in your application and the native interop libraries should be deployed in platform-specific sub-directories underneath that directory, as follows: \YourApp.exe \System.Data.SQLite.dll (managed-only assembly) \x86\SQLite.Interop.dll (x86 native-only interop library) \x64\SQLite.Interop.dll (x64 native-only interop library) If this feature does not work properly in your environment, it can be disabled by setting the "No_PreLoadSQLite" environment variable prior to loading and/or using the System.Data.SQLite assembly. -- Joe Mistachkin = end of original message This is the first I have heard of this feature or requirement or whatever this is. This statement seems to be saying that the "System.Data.SQLite managed-only assembly" is different from the "System.Data.SQLite assembly". Is that true? When I download a new version of the System.Data.SQLite installation package, how will I tell the difference between the two? RobR ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] ADO.NET Provider, targeting any cpu
2012/5/23 Joe Mistachkin > > Damien wrote: > > > > Is there a way to have an assembly targeting "any cpu", that chooses by > > itself the right dll to use at runtime ? > > > > The System.Data.SQLite managed-only assembly, when the native library > pre-loading code is enabled (which it is by default starting with > release 1.0.80.0), will now attempt to detect the processor architecture > of the process it is being loaded into and then it will attempt to load > the native interop library from an appropriately named subdirectory (e.g. > "x86", "x64", etc). In order to take advantage of this feature, the > System.Data.SQLite managed-only assembly should be deployed with the > other managed binaries in your application and the native interop > libraries should be deployed in platform-specific sub-directories > underneath that directory, as follows: > >\YourApp.exe >\System.Data.SQLite.dll (managed-only assembly) >\x86\SQLite.Interop.dll (x86 native-only interop library) >\x64\SQLite.Interop.dll (x64 native-only interop library) > > If this feature does not work properly in your environment, it can be > disabled by setting the "No_PreLoadSQLite" environment variable prior to > loading and/or using the System.Data.SQLite assembly. > > Tested and working. Thanks :) Damien ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] ADO.NET Provider, targeting any cpu
Damien wrote: > > Is there a way to have an assembly targeting "any cpu", that chooses by > itself the right dll to use at runtime ? > The System.Data.SQLite managed-only assembly, when the native library pre-loading code is enabled (which it is by default starting with release 1.0.80.0), will now attempt to detect the processor architecture of the process it is being loaded into and then it will attempt to load the native interop library from an appropriately named subdirectory (e.g. "x86", "x64", etc). In order to take advantage of this feature, the System.Data.SQLite managed-only assembly should be deployed with the other managed binaries in your application and the native interop libraries should be deployed in platform-specific sub-directories underneath that directory, as follows: \YourApp.exe \System.Data.SQLite.dll (managed-only assembly) \x86\SQLite.Interop.dll (x86 native-only interop library) \x64\SQLite.Interop.dll (x64 native-only interop library) If this feature does not work properly in your environment, it can be disabled by setting the "No_PreLoadSQLite" environment variable prior to loading and/or using the System.Data.SQLite assembly. -- Joe Mistachkin ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] ADO.NET Provider, targeting any cpu
Hi, I don't know if question has already been asked, and i appologize if it is the case... For the SQLite ADO.NET provider, there are precompiled binaries for both x86 and x64. Is there a way to have an assembly targeting "any cpu", that chooses by itself the right dll to use at runtime ? I did something like this some time ago : 2 classes, one for x86 dll, one for x64 dll, implementing same interface. And at runtime, a function to get the right "native methods class", by trying to load one, and catch "BadImageFormatException", trying next... Thanks. Damien ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users