I have two versions of System.Data.SQLite.DLL - for x86 and x64 platform. The x86 version keeps in application folder and x64 version keeps in appFolder\x64 folder. The application compiled as AnyCPU. How can i load needed version of SQLite according to windows platform?
+1
A:
You could use Environment.Is64BitProcess to identify the process as 64 bit. (I would try to avoid catching exceptions as flow-control wherever possible.)
Paul Ruane
2010-09-24 13:23:44
It's good proposition but it don't solve my problem.
Rover
2010-09-24 13:28:09
@Rover: How so? Do you definitely have 64 bit .NET installed?
Paul Ruane
2010-09-24 13:42:30
I use .NET 3.5 that not have this variable. I think i can check the version of platform but it only avoid catching some exceptions but needed assembly is not loaded.
Rover
2010-09-24 13:55:41
@Rover: Ah hah, I am with you now. You are saying that the 64 bit assembly fails to load on 64 bit platform, rather than that you don't know how to detect the local platform?
Paul Ruane
2010-09-24 14:11:07
The problem is loading of needed assembly :)
Rover
2010-09-24 14:14:14
@Rover: OK, would it not be possible to check the Environment.Is64BitProcess and then, depending upon the result, load either the 32 bit library (Environment.Is64BitProcess = false) or the 64 bit library (Environment.Is64BitProcess = true)?
Paul Ruane
2010-09-24 14:26:16
@paul-ruane: How can i load assembly to AppDomain?
Rover
2010-09-24 14:30:15
A:
Couldn't you just use the source of SQLite as a separate project in your solution instead of a precompiled assembly? Using AnyCPU the system itself will take care of everything and you don't have to do it in code...
Tim Robbin
2010-09-24 13:24:19
It's one of dlls that i use which divided on x86 and x64. I don't have source code of all used dlls.
Rover
2010-09-24 13:31:25
+1
A:
I'm surprised that this works at all. It should find the x86 version first and fail. A failed assembly bind doesn't produce another attempt through AssemblyResolve.
Clearly, the CLR cannot actually find the x86 version or this would fail in x64 mode as well. In other words, when you fix the problem, you'll break the 64-bit code. Chase the x86 problem first, use Fuslogvw.exe to see which folders are being probed for the assembly.
A real fix should include moving the x86 assembly into a separate folder as well and adjusting your event handler accordingly. You can test IntPtr.Size to find out if you're running in 64-bit mode (Size == 8). Also be sure to generate a full path name, using the relative path like you do now can cause failure when the app's working directory isn't set where you hope it is. Assembly.GetEntryAssembly().Location gets you the path of the EXE.
Hans Passant
2010-09-24 14:00:42
Hmm, I don't think that changes my answer. The last paragraph tells you how to do it right.
Hans Passant
2010-09-24 14:17:35
Ok, i checked platform, found needed assembly. What should i do for loading of assembly to AppDomain?
Rover
2010-09-24 14:32:58
You mean you want to load it in a non-default AppDomain? Better start a new question for that.
Hans Passant
2010-09-24 16:17:19