Question

I understand WHY the System.Data.SQLite.dll is provided in 32 bit and 64 bit builds. So lets not dwell on that and move on. 🙂

Since it is done this way it seems to make pure C# development a tad more difficult with 3 choices to make.

1. Is to support only 32-bit and force there managed
   assembly to compile x86 and deal with that in running in 32 or 64
   bit, and there by lose advantages of when you are on a 64 bit
   environment.

2. Is to force 64 bit and only support 64 bit and losing the
   ability to run on 32 bit but gaining all the advantages of 64 bit.

3. Is to create two versions of their assembly one that
   compiles x86 and uses 32 bit SQLite and another that compiles x64
   and uses 64bit SQLite. It prevents using “ANY” as a compile option
   and being able to easily deploy a single build to either type. Its
   not so horrible to manage from a development point of view as we
   will need two projects. Only having the C# code officially in one,
   and the other will just use “links” to the code in the other. This
   is for compiling purposes only. Still leaves us with having to
   manage two outputs to for deployments.

With all that said I am only looking for confirmation that the above are the only correct choices.

If however there are other choices that I am overlooking please let me know. Specifically if there is way to get a single C# DLL that can compile to ANY so it can take advantage of 32 or 64 bit depending on where its run and still use System.Data.SQLite.dll.

Answer 1

There are 2 common solutions for keeping your main application at AnyCPU:

• Install both the x86 and the x64 assemblies into the GAC: They can (should!) have identical assembly names and the GAC will automatically decide whether to use x86 or x64 version.

• Hook into AppDomain.AssemblyResolve and serve the right assemblies from subdirectories using Assembly.LoadFrom