Data. SQLite. dll can be considered as sqlite3.c written in C.. NET platform encapsulation, because the original sqlite3.dll is differentiated between x86 and x64 release, Data. SQLite. in general, dll will also differentiate between x86 and x64 encapsulation, and the result may be troublesome in actual use.
From Data. SQLite. as you can see in the source code of the dll, the solution includes two parts of the project, one part is the C # project, and Data will be generated. SQLite. dll and Data. SQLite. linq. dll; the other part is the C/C ++ project, which will generate SQLite. interop. dll. If some configuration is performed on the source code, a file will be generated, that is, the commonly used Data. SQLite. dll, which can be seen from the files marked with "bundle" on the official website, but not those marked with "bundle", which will contain SQLite. interop. dll. In the C # section, "UnsafeNativeMethods. the cs file defines the relationship between the two parts, that is, the file uses DllImport to import SQLite. interop. dll, and the path can be under the current directory, or under the Win32, x86, x64, and other directories of the current directory. These are the basic internal structures of Data. SQLite. dll.
Data. sqlite. the dll source code uses two types of C/C ++ and C # interaction methods, both of which can be achieved in.. NET platform uses C/C ++ code. One is to use the C # code as the main body, and import the C/C ++ dll, this will generate multiple dll. Another method is to import the C # module with the C/C ++ code as the main body, so that only one dll is generated.
Because the C/C ++ project exists in the solution, AnyCPU cannot be generated, so the program that references this dll must be generated in AnyCPU, this dll may cause problems. The only solution found so far is,The Data generated by the C # project. SQLite. dll and x64 SQLite. interop. dll, The x86 version of SQLite under the x86 directory. interop. dll is used together. In use, you only need to reference Data. SQLite. dll, which internally calls different SQLite. Interop. dll based on the current platform, so as to achieve compatibility with AnyCPU.
The above method can achieve cross-x86 and x64 platforms. However, if the program that references this dll is not necessarily generated under AnyCPU, there is a more convenient method,Generate the program that references the dll in x86. The dll only uses the version of the released 32 platform.
Other possible problems, such as normal debugging, abnormal Release, normal Console, abnormal WinForm, normal Win32, and abnormal Win64, etc, if you can accept non-optimized Debug Versions, programs that do not use Winform, or use only one platform, you do not have to be as complicated as I said. If the requirements are strict, you can try the solution I mentioned above.
All Comments are Welcome.