title: DLL hell with SQLite
body: <p>Some of our users are getting an issue with the version of sqlite.interop.dll that is being loaded at runtime, and it's a real head scratcher.</p>
  
  <p>Background:
  A WPF application built for AnyCPU, deployed with SQlite .NET and sqlite.interop.dll version 1.0.89. We deploy both x86 and x64 dlls and employ the delay loading included with SQLite.
  This has been fine until recently, when we started getting a few support issues from users that had - typically - recently purchased new Dell machines. It seems that there is an older version of sqlite.interop.dll (v.1.0.80) that, <em>somehow</em>, is getting loaded in preference to the one we ship. The error we get is a missing entry point, 'sqlite3_changes_interop'.</p>
  
  <p>What we have tried:</p>
  
  <ol>
  <li><p>Changing the setup to simply copy the appropriate dll (x86/64) to the same directory as the executable during installtion (i.e. no separate x86/x64 folders). This means we no longer use the delay loading, as the correct dll is available in the executable directory (although we haven't explicitly disabled the delay loading mechanism in sqlite.net). This doesn't fix the problem..</p></li>
  <li><p>Explicitly loading sqlite.interop.dll when the application first loads. Again, this does not seem to fix the issue.</p></li>
  </ol>
  
  <p>It seems that the ordering of dll loading locations has been changing somewhat in recent years, and I may not have a good handle on it. I always assumed that a dll in the executable directory would get first preference, and that a dll that had been explicitly loaded would prevent the same dll being reloaded during the application lifetime, so for the life of my I cannot understand what is going on here.</p>
  
  <p>Can anyone shed any light on what might be happening here? The problem is further compounded by the fact that I simply cannot reproduce the problem locally - e.g. by putting the wrong version of the dll in my system path etc. Which makes me think that maybe the GAC might be coming into play?</p>
  
  <p>Really stuck on this one, so any help would be great.</p>
  
  <p>Also - as a final resort - I might consider reverting to the same 1.0.80 version, so that we don't get this issue. Does anyone know where we could source older versions of sqlite.net and sqlite.interop.dll?</p>
  
  <p><strong>Edit - some additional information:</strong></p>
  
  <p>The clash is caused by a copy of sqlite.interop.dll version 1.0.80 that is installed with Dell Backup and Recovery. This is installed on all new Dell machines, and users that install our software on such a machine all experience this issue. This Dell software also uses System.Data.SQLite.dll.</p>
  
  <p>The correct version of sqlite.interop.dll is located in the same directory as our executable, and everything I understand about dll loading suggests that this should be loaded in preference.</p>
  
  <p>Although we have not yet been able to reproduce the issue locally, it appears that the bad version of interop.dll is <em>not</em> on the path. Furthermore, the Dell backup utility runs automatically on start-up. Does anyone know of any possible mechanism by which this might be hooking into dll load requests and serving the wrong file? </p>
  
  <p>The current line of thinking is that we might build our own System.Data.SQLite.dll and change the interop loading code to a specifically named version (e.g. sqlite.interop.1.0.89.dll). Not a nice solution going forwards, but..</p>