System.Data.SQLite

Hi,

when SQLite is used in MS Office .NET add-ins, an error can occur in a special environment: If the add-in is running as 32-bit add-in in a 32-bit Office implementation, whereas the Windows version is 64-bit, the non-bundled SQLite DLL does not run because the wrong SQLite.Interop version is called-up. I guess the 64-bit version is called up although the 32-bit version should be called up.
I have not checked the System.Data.SQLite code, but I assume that there is no proper check in which mode the .NET-add-in is actually running (32-bit or 64-bit). In this special case (32-bit office on 64-bit Windows), it is not sufficient to check for the Windows version!

Please check and let me know if there is a chance to fix this issue. Currently, I need to deploy two add-in versions (32-bit and 64-bit) with the appropriate bundled SQLite.Data version. This is a workaround that works, but it is a bit cumbersome and error-prone.

Best regards
Hermann

Have you read about the "native library pre-loading feature"?

From the [/doc/trunk/www/downloads.wiki] page:

The final step is to identify the target processor architecture on both the development and customer machines. Generally, x86 binaries will work on an x64 machine running Windows (using WoW64). However, there is a problem when using managed code. If the executable that starts the process consists entirely of managed code, it will run with the native processor architecture of the machine, which will be x64 on an x64 machine. Later on, this will cause assemblies containing any native code compiled for x86 (e.g. the "System.Data.SQLite.dll" mixed-mode assembly, the "SQLite.Interop.dll" native interop assembly, or the "sqlite3.dll" native library) to fail to load, typically resulting in a BadImageFormatException being thrown.

If the development and customer machines may have different processor architectures, more than one binary package may be required. For this situation, using the native library pre-loading feature is highly recommended. It is available as of version 1.0.80.0 and enabled by default. In order to take advantage of this feature, the separate managed and interop assemblies must be used with XCOPY deployment (i.e. this feature is not supported by the mixed-mode assembly, nor when the assembly is deployed to the global assembly cache), resulting in an application deployment that looks something like this:

    * <bin>\App.exe (optional, managed-only application executable assembly)
    * <bin>\App.dll (optional, managed-only application library assembly)
    * <bin>\System.Data.SQLite.dll (required, managed-only core assembly)
    * <bin>\System.Data.SQLite.Linq.dll (optional, managed-only LINQ assembly)
    * <bin>\x86\SQLite.Interop.dll (required, x86 native interop assembly)
    * <bin>\x64\SQLite.Interop.dll (required, x64 native interop assembly)
	 
The string "<bin>" above represents the directory where the application binaries are to be deployed on the target machine. With the native library pre-loading feature enabled and the application deployment shown above, the System.Data.SQLite managed-only assembly will attempt to automatically detect the processor architecture of the current process and pre-load the appropriate native library.

If native library pre-loading feature does not work properly in your environment, it can be disabled by setting the "No_PreLoadSQLite" environment variable (i.e. to anything) prior to loading and/or using the System.Data.SQLite assembly. There are several more environment variables that can be used to influence the behavior of the native library pre-loading feature, documented here: [/artifact?ci=trunk&filename=Doc/Extra/environment.html].