|Title:||Consider alternatives to adding the Bin directory to the system path|
|Last Modified:||2011-07-07 04:38:18|
|Version Found In:||18.104.22.168|
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:
anonymous added on 2011-06-13 15:28:57 UTC:
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).
anonymous added on 2011-06-13 16:37:28 UTC:
mistachkin added on 2011-07-01 04:24:25 UTC:
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.
anonymous added on 2011-07-01 06:27:53 UTC:
The resolution "Rejected" is not quite right. With [3.] the issue is going to be actually "Fixed". Thank you for the great job.
mistachkin added on 2011-07-01 11:06:18 UTC: