|Title:||Wrong processor architechture detected in System.Data.SQLite.dll while running out of visual studio|
|Last Modified:||2013-07-15 18:48:16|
|Version Found In:||22.214.171.124|
anonymous added on 2013-04-10 08:28:16:
We’re using SQLite in a mixed environment. The host application is written in Delphi and compiled as 32-bit process. This application calls .Net code that uses SQLite. The .Net assemblies are currently compiled using architecture “AnyCPU”. If I start the main application itself all is working correct. The environment variable “PROCESSOR_ARCHITECTURE“ is set to „x86“. If I start the same host application out of visual studio running on a x64 OS the variable is set to “AMD64” (in my case) which is not correct for the currently running process. The method UnsafeNativeMethods.PreLoadSQLiteDll(..) uses this environment variable to determine the architecture and tries to load the needed assembly. The only thing to do is to check whether the currently running process is a 32-bit or 64-bit process, isn't it? It would be possible to use the properties “Is64BitOperatingSystem” (true in my case) and “Is64BitProcess” (false in my case). Both are set correct even if visual studio starts the process. If you’ll use these properties it would be possible to use SQLite out of visual studio having a x86 host application and an “AnyCPU” compiled assembly that references SQLite started on a 64-bit OS.
mistachkin added on 2013-04-10 11:18:34:
First, I've never seen the PROCESSOR_ARCHITECTURE environment variable set to the wrong value. Is it possible that some other component in the process is setting it? Second, if you are running a pure managed executable assembly on an x64 machine, the environment variable should indeed be "AMD64". In that case, you'll want to make sure that both the x86 and x64 SQLite interop assembly files are available and are deployed to the correct directories within the application binary directory. Since the PROCESSOR_ARCHITECTURE environment variable value itself is used to help construct the final file name for the SQLite interop assembly, simply using a binary (yes/no) check for a 64-bit process will not be a drop-in replacement, nor should it be necessary in this case. Finally, if the PROCESSOR_ARCHITECTURE environment variable is indeed being set to the wrong value for the process by the operating system (i.e. due to a bug), it can be easily overridden by the application prior to loading the System.Data.SQLite assembly, for example: Environment.SetEnvironmentVariable("PROCESSOR_ARCHITECTURE", Environment.Is64BitProcess ? "AMD64" : "x86"); However, it should be noted here that assuming a 32-bit process is "x86" (or that a 64-bit process is "AMD64") may not always be true, due to things like 32-bit ARM, etc.
anonymous added on 2013-04-10 11:29:45:
Please take a look at the following blog entry - it describes exactly my problem: http://lesscode.net/blog/2011/3/31/processor_architecture-and-visual-studio-debugging.html
mistachkin added on 2013-04-10 11:40:35:
That may be caused by this: http://stackoverflow.com/questions/6749187/why-does-createenvironmentblock-on-a-wow64-process-give-me-processor-architectur Or it could just be an issue with Visual Studio. Either way, my original comments are still valid.
mistachkin added on 2013-07-15 09:23:22:
I've now seen this issue occur from within Visual Studio 2012 running on a 64-bit Windows 7 machine. It appears to require the "Prefer 32-bit" project option to be enabled. This appears to be a bug in the operating system and/or Visual Studio.
mistachkin added on 2013-07-15 09:28:59:
Screenshots with proof of issue added.
mistachkin added on 2013-07-15 18:48:16:
Workaround implemented by check-in [f54929f54e] on trunk. This will be in the next release, 126.96.36.199.