Problem Solved!
The issue was that the solution that was failing had different test
settings. Not sure how the settings got changed but somehow the unit test
project was configured to run as if an ASP.NET application. Changing the
solution test settings file to the default Local test settings caused
SQLite to look in the right place, running as a normal host instead of an
ASP.NET proxy host.
So the moral of the story is if you're seeing this in your unit tests, make
sure you're not accidentally running somehow as an ASP.NET host.
At last, all is well.
- Bob
On Tue, Oct 9, 2012 at 3:52 PM, Robert Calco <bobca...@gmail.com> wrote:
> Hi Joe,
>
> On Tue, Oct 9, 2012 at 10:56 AM, Joe Mistachkin <sql...@mistachkin.com>wrote:
>
>>
>> Robert Calco wrote:
>> >
>> > Dependency Walker is complaining that SQLite.Interop.dll needs but
>> cannot
>> > find IEShims.dll. This DLL is present on my system twice, in the program
>> > files directory of both x86 and x64 versions of Internet Explorer,
>> > respectively.
>> >
>>
>> That appears to be a delay-load issue. Those are normally harmless.
>>
>
> It is when I open the x64 SQLite.Interop.dll in Dependency Walker. Just
> the two warnings.
>
> But when I open the x32 SQLite.Interop.dll in Dependency Walker, it gives
> me an error:
>
> "Errors were detected when processing "<path>\x86\SQLITE.INTEROP.DLL". See
> the log window for details."
>
> ANd the two errors are:
>
> Error: At least one module has an unresolved import due to a missing
> export function in an implicitly dependent module.
> Error: Modules with different CPU types were found.
>
> That last one is what has me scratching my head. All the system DLLs are
> 64-bit (and show red x64 in the CPU column). And still that IEShims.DLL
> cannot be found.
>
> The kicker though: this doesn't seem to pose a problem in one solution,
> but it does in another, when they are referencing the same binaries, and
> they have the same problem when I load them in Dependency Walker!
>
> No, putting the SQLite.Interop.dll in the bin directory doesn't help,
> either.
>
> -- Bob
>
>
>> >
>> > I have used NuGet to install SQLite into all three. I'm going to remove
>> it
>> > from the projects in the WPF and WCF solutions, leaving it only in the
>> > Shared solution, and resolving all references to the SQLite binaries in
>> the
>> > shared solution, for starters.
>> >
>>
>> I've never tried to add the same NuGet package to multiple projects in a
>> single solution before. I'm not sure what happens in that case.
>>
>> Something that could give us some clues here are the trace diagnostics
>> emitted
>> by the native library pre-loading feature. Is it possible for you to
>> modify
>> your project and add a trace listener prior to using any of the
>> System.Data.SQLite
>> classes? If so, you should see output similar to:
>>
>> Trying to load native SQLite library \"{0}\"...
>> Failed to load native SQLite library \"{0}\" (getLastError = {1}):
>> {2}
>>
>> Also, if your application is part of a web application or is being
>> deployed
>> to a
>> location where the "SQLite.Interop.dll" files will not be present in the
>> appropriate
>> processor architecture sub-directories, you can use the
>> "PreLoadSQLite_BaseDirectory"
>> environment variable to indicate where the native library pre-loading
>> feature should
>> look. See the following docs for more information:
>>
>>
>> http://system.data.sqlite.org/index.html/artifact?ci=trunk&filename=Doc/Extr
>> a/environment.html<http://system.data.sqlite.org/index.html/artifact?ci=trunk&filename=Doc/Extra/environment.html>
>>
>> --
>> Joe Mistachkin
>>
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
>
>
>
> --
> *Bob Calco*
>
>
>
--
*
*
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
