I ran this utility and what I discovered is problematic. On my development machine, it is always looking for this dependency in the GAC first and loading it from there. as opposed to the start-up folder where the DLL is located. Why is this looking for the DLL in the GAC first? This is not normal windows behavior. I then uninstalled the SQLite setup bundle and ran the program again and according to the utility, it fails finding the DLL in the GAC and loads it from the start-up folder. This is the behavior on both Windows 7 and 8.
On windows 10, which is a basic install of the preview, one for 64 bit and one for 32 bit, and without any development tools installed, or the SQLite setup bundle installed, it failed to find system.data.sqlite.dll. The first thing I did on my 64 bit was to install the x86 setup bundle. Now the program runs and loads the dll from the GAC. I then uninstalled the setup bundle and tried the program again, and I'll be damned it now runs and find the DLL in the launch folder. Why is that??? Tried the program on a fresh install of the 32 bit win10 and it failed, unable to located the DLL. I loaded up the SDKs' so I could get the fuslogvw utility. With the utility running ran the program and It now runs and find the dll in the executable folder. What's up with this??? I suspect this might be a Windows 10 issues, but why is it looking for the DLL in the GAC first and not in the executable folder which has been the behavior of windows for the last 20 some odd years I have been working with this pig. Jeff K. Steinkamp (N7YG) Tucson, AZ Scud Missile Coordinates N32.2319 W110.8477 On 3/18/2015 13:09, Nicholas Smit wrote: > 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 >> > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > >
