fuslogvw ( https://msdn.microsoft.com/en-us/library/e74a18c4%28v=vs.110%29.aspx ) might help you understand the DLL binding issue.
On 18 March 2015 at 20:04, Jeff Steinkamp <n7yg at n7yg.com> wrote: > One of my users reported that he was unable to get a piece of software > that uses this .NET assembly (x86 version 1.0.9.6) to run on windows 10. > It is throwing an error saying that it is unable to located > system.data.sqlite.dll even though it is included in the same folder as the > program executable. > > This software is compiled as x86 because of some other included assemblies > are complied as x86. This has been running just fine on both Win7 and Win8 > both 32 and 64 bits this way for quite some time. > > So, I setup a 64 bit Win10 technical preview in a VM and tried it myself > and I got the same error. I tired forcing the loading of the assembly, but > it would puke all over itself with the "your application quit and windows > will get back with you when hell freezes over" > > So I loaded up the SQLite setup bundle for both the X86 and X64 and had > them install into the GAC (Global Assembly Cache) and now the software > works. So this is telling me that Windows 10 is only looking in the GAC > for this assembly. Any idea why this might be as I have two other .NET > assemblies that are used in this software that it does not have trouble > finding and they are not installed in the GAC? > > I suspect this may be a Mico$oft Issue, but wanted to check here first to > make sure I have not got something setup incorrectly. > > -- > Jeff K. Steinkamp (N7YG) > Tucson, AZ > Scud Missile Coordinates > N32.2319 W110.8477 > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
