System.Data.SQLite

 Hi Robert,

I am searching a way to compile my C# software in an universal build (Any CPU). Compiling and releasing two versions of my app is quite boring and should be avoid with managed code.

At runtime, my app should be capable to switch on 32 or 64 bits native librairies.

The component SevenZipShrap (http://www.codeplex.com/sevenzipsharp) use a such system:

 "SevenZipSharp requires a 7-zip native library to function. You can specify the path to a 7-zip dll (7z.dll, 7za.dll, etc.) in LibraryManager.cs at compile time, your app.config or via SetLibraryPath() method at runtime. <Path to SevenZipSharp.dll> + "7z.dll" is the default path. For 64-bit systems, you must use the 64-bit versions of those libraries."

What do you think about a comparable mechanism for SQLite?

Thanks a lot for your SQLite provider.

Best regards

Cyber Sinh

 Why would I use a factory if I don't want to use different database provider?

The problem is that I would like to  release only one version of my managed app (for 32 bits and 64 bits).

I could do it with the managed only provider but there is no way to specify at runtime the path of the native SQLite dll, like that:

if (IntPtr.Size == 8)

 provider.SQLitePath = "x64\sqlite.dll";

else

provider.SQLitePath = "x86\sqlite.dll";

Robert, what do you think about it?

 Hello

I am new here and would also like to cast a vote for this feature request. If there is a better and more formal way of doing this then please let me know.

Of course it is possible to get your System.Data.SQLite enabled application to run as a 32 or 64 bit process. However, the only straight forward way of doing so requires the distribution of two separate install-packages. If your distributing your application over the internet, then many users will download the wrong install-package because they don't know if they have a 32 or 64 bit OS. If you have many potential customers you simply can't afford the resulting support requests. Although the number of applications that benefit from running as a 64 bit process are in the minority, we should still strive to provide a single install-package that works optimally in both scenarios.

Microsoft's SQL Compact 3.5 provider can do this. It will load different native dll's depending on weather the provider was loaded into a 32 or 64 bit process.

MS Sql Compact does this by installing to the GAC, which loads the correct bitness from the gac.

Hi Robert. BTW: thanks for all your work on this project!

Possibly, but not necessarily. You can do an xcopy deployment where the ado.net provider is in the same directory as your application. Below that xcopy needs to create two directories named x86 and amd64 in which the the 32 and 64 bit native binaries are placed. Nothing needs (or should) be installed in the GAC. System.Data.SqlServerCe.dll will bind to the correct native binaries.

http://blogs.msdn.com/stevelasker/archive/2008/10/22/privately-deploying-sql-server-compact-with-the-ado-net-entity-provider.aspx

However, due to the way the runtime binds to assemblies, the runtime will always load the assembly from the GAC as long as the version matches (as you said). In this scenario SQL Compacts concept of a private deployment goes out the window. SQL Server Compact 3.5 SP2 will fix this by providing a second copy of the ado.net provider with a different assembly version which is not intended to get installed into the GAC. This copy is part of the SP2 Beta (see the file ..\Private\System.Data.SqlServerCe.dll)

http://www.microsoft.com/downloads/details.aspx?FamilyID=411ba1c5-ba57-45b6-9148-91bed6e7a9f1&displaylang=en

Kind Regards -- ascent