One possible alternative is to discover the location of the DLL (using some rules, conventions, etc.) and to load the required SQLite.Interop.dll "manually" using its explicit path discovered before the first call to it.
This technique is described in here:
http://stackoverflow.com/questions/530143/can-net-pinvoke-dynamically-load-a-native-dll-from-a-user-specified-directory/530169#530169
<hr /><i>anonymous added on 2011-06-13 15:28:57 UTC:</i><br />
I have just found a practical example of using this technique. It is the open source library NHunspell:
http://nhunspell.sourceforge.net/
As far as I can see, its bin directory contains the .NET assembly NHunspell.dll (common for all platforms, it could be System.Data.SQLite.dll in our case) and platform specific native core DLLs (Hunspellx64.dll, Hunspellx86.dll, they could be SQLite.Interop.x64.dll and SQLite.Interop.x86.dll in our case).
The method that discovers and loads the proper DLL and imports its functions as delegates is: NHunspell.MarshalHunspellDll.LoadNativeHunspellDll(). The sources are available, take a look at the project repository. Alternatively, ILSpy can be used in order to take a look at the decompiled code right from the NHunspell.dll (that is what I did).
Note that NHunspell does not discover the directory path of its native DLLs itself. Instead, it has the static property NHunspell.Hunspell.NativeDllPath. This approach is very flexible, indeed, but it requires that this property is set by a client. This could be enhanced, IMHO. For example, if it is not set then it is automatically discovered according to reasonable conventions, e.g. the path is the directory where the executing NHunspell assembly is (this is normally the case).
<hr /><i>anonymous added on 2011-06-13 16:37:28 UTC:</i><br />
Correction: it looks like NHunspell actually uses the default path; it is the application home directory.
<hr /><i>mistachkin added on 2011-07-01 04:24:25 UTC:</i><br />
There are various existing solutions to this problem that do not require adding the bin directory to the system path:
1. Deploy the managed-only System.Data.SQLite.dll and the native-only SQLite.Interop.dll as "application local" along with the application binaries.
2. Use the Environment.SetVariableValue method to add the application deployment directory to the PATH prior to creating any System.Data.SQLite objects.
3. Use the mixed-mode assembly that contains all the necessary native and managed code in one DLL. Optionally, this DLL may be GAC'd.
In the next release, there will be a mixed-mode setup bundle for each supported architecture to make #3 easier.
<hr /><i>anonymous added on 2011-07-01 06:27:53 UTC:</i><br />
It looks like [3.] + GAC will be the best solution for all my scenarios (numerous small applications and PowerShell scripts).
The resolution "Rejected" is not quite right. With [3.] the issue is going to be actually "Fixed". Thank you for the great job.
<hr /><i>mistachkin added on 2011-07-01 11:06:18 UTC:</i><br />
Resolution changed.
|
