Currently, SQLite.NET only ships as either x86 or x64 build. Thus, it is currently not possible to create a .NET application in "Any CPU" configuration if you want to use SQLite.NET, which is quite sad.
However, this would very well be possible without big efforts: You do already create a non-mixed-mode version. You could just build the .NET part of it as "Any CPU" and deliver it with both the x86 and x64 interop dll (in separate folders). Then the main project can be compiled as "Any CPU" as well. Then either the application's installer can take care of installing the correct interop dll based on the system type, or the application can load the dll(s) manually using LoadLibrary at startup, or it can use the SetDllDirectory API function at startup to point to the correct sub directory so the x86/x64 directory will be used as additional lookup directory automatically (probably the best solution if you have more than one native dll).
I am already referencing three other "mixed" components using this approach successfully. It would be great to have SQLite.NET also support this configuration!
<hr /><i>mistachkin added on 2011-12-07 22:16:18 UTC:</i><br />
Firstly, the core SQLite library itself is native; therefore, at some point during the build process a decision must be made regarding which native platform is to be targeted by the resulting executable files (i.e. DLLs and/or EXEs).
In theory, the build process could be modified to build for multiple configurations at the same time; however, since the "Batch Build" feature in Visual Studio already supports doing this there is not a large motivation to build this feature into the project build infrastructure itself. Also, even when building via the command line using MSBuild, building multiple configuration is trivially easy, including via some external automation, such as batch files or scripts.
The other issue you mention has to do with the installer used by the application. As you mention, this task is completely specific to each application being deployed and must take into account which architecture(s) are to be supported and install the necessary native DLL(s) accordingly. In fact, the project has indirect support for this using the "managed-only" assembly (which can work with either the 32-bit or 64-bit native DLL). The specific native DLL (32-bit or 64-bit) used by the managed-only assembly depends on the architecture of the process and machine the code is being executed in/on.
<hr /><i>anonymous claiming to be fastcat@gmail.com added on 2011-12-07 23:30:16 UTC:</i><br />
AFAICT what the submitter wants is already done ... because it is exactly how I use it in my app now, with unmodified binaries from the downloads page.
The managed only assembly already is AnyCPU. I drop it in the main app folder, and the two copies of SQLite.Interop.dll in x86 and x64 subdirectories, and call SetDllDirectory early in app startup, exactly as the submitter describes. Works perfectly, no changes needed.
I suppose the only thing that could save about 10 seconds of time when updating my copy of SQLite would be to have a single zip that has the managed only assembly and the interop DLLs for all architectures in it, but that hardly seems worth it. The downloads page is long and sometimes confusing enough as it is.
<hr /><i>anonymous claiming to be anonymous (original poster) added on 2011-12-08 13:38:53 UTC:</i><br />
Hello, I am the original poster of this ticket. It seems I have checked that with the wrong dll, probably I took the mixed mode assembly accidentally. I can confirm that the requested functionality is already available with the non-mixed-mode builds!
So I am setting this to closed. There is no need to create an additional download only for the combined interop dlls.
|
