[sqlite] system.data.sqlite.dll and Widows 10
There were some complaints registered previously with windows about this issue where it looks first in the program root for a DLL and then the GAC. This is actually unwanted behaviour since if you use a 3rd party DLL (let's take the library for Google's Chrome browser as an example) in your program - which is the entire beauty of linked libraries - and then you update the chrome browser on your machine... the Chrome installer doesn't know who all uses the dll and it can only really update the one in the GAC. When you write the software, you of course include the DLL in the distribution because you don't know whether a target machine will possess a Chrome install - but you would like your program to really use an updated DLL if it ever finds one, so loading from GAC first then local is the correct behaviour - Windows knows this but they have been doing it wrong for legacy reasons, so now maybe they are trying to fix it in Win10. (I say maybe cause I am not privy to their decision chain and all this is speculation in service of offering a plausible reason). It goes both ways however: if an older sqlite3.dll somehow finds it's way into the GAC (older than 3.7) then things I've made will break horribly. Either way, I am with you on the issue - it's best to leave it as is since a large percentage of existing programs knows it and deals with it - It isn't hard to specify loading a DLL from file if you so prefer, but it does pose a problem for newer user-centric developers such as VB, VS and users not knowing or caring to "deal" with DLL loading issues etc. - maybe it's time to do it right - A bit of warning would be welcome though. If I have to guess, they will probably do the standard WIndows thing which works like this: We've been doing it like XXX - not perfect but everyone learned to use it this way, Some users cried and we realised YYY is better, so we changed to YYY, Users cry about the change, so we change YYY to work a bit like XXX, Other users cry more so we make XXX v2.0 superseding YYY with unneeded version control, security prohibitions and a host of other nonsense so accommodate everybody sort-of but nobody perfectly - and then find a way to market this as a "feature". Best of luck to you, Ryan On 2015-03-20 07:05 AM, Jeff Steinkamp wrote: > 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 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
[sqlite] system.data.sqlite.dll and Widows 10
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 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 > >
[sqlite] system.data.sqlite.dll and Widows 10
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 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] system.data.sqlite.dll and Widows 10
It might also be the runtime; was trying to install a debug version at one point and msvcr110d.dll was missing... maybe it's just that the required runtime is missing yet? It also just threw an error 'cannot locate' On Wed, Mar 18, 2015 at 1:09 PM, 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 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 >
[sqlite] system.data.sqlite.dll and Widows 10
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
