System.Data.SQLite

We have had a number of users run into this issue. Here's an easy way to reproduce the problem. Make sure there isn't a reference to System.Data.SQLite in your machine.config (users probably wouldn't have that). Build an application using the 1.0.65.0 version of system.data.sqlite and system.data.sqlite.linq and use them in your application's directory instead of in the GAC. Everything should work fine. Now install the 1.0.66.0 version of System.Data.SQLite to the GAC and also the equivalent System.Data.SQLite.Linq (which has version number 2.0.38.0). Try to run your app. You will get System.Data.SQLite.SQLiteConnection InvalidCastException. The problem seems to be that System.Data.SQLite.Linq's version number is always the same. So when you load 2.0.38.0 it loads the one in the GAC which uses system.data.sqlite 1.0.66.0. This is not the version you are using and you get a cast error. If put the version of system.data.sqlite.linq that you are using into the GAC, you could break someone else's app, so that's not a solution either. You can verify this problem looking at the 1.0.66.0 and 1.0.65.0 versions of System.Data.SQLite.Linq in .NET Reflector. They have the same version number and public key but reference two different versions of System.Data.SQLite. System.Data.SQLite.Linq needs to update its version number when System.Data.SQLite changes.

We also ran into this problem with a customer who had 1.0.61.0 in the GAC. We try to use a local copy of 1.0.66 but in this case it failed with the SQLiteConnection InvalidCaseException. Uninstalling System.Data.SQlite.Linq from the GAC solved the problem, indicating the scenario described above is probably correct. This is not something that can be done in general, of course, since it may mess up another application. Are there any plans for a new release that increments the version of System.Data.SQlite.Linq to avoid this problem?

I found a fairly straightforward way to avoid this problem while playing nicely with other apps that insist on installing themselves to the GAC.  Your app does not need to install SQLite to the GAC, or alter anything that was installed to the GAC by another app for this fix to be effective.

The basic idea is to allow the .NET runtime to load System.Data.SQLite.Linq from the GAC and redirect the binding to System.Data.SQLite such that it will always select the version required by your app.  I have tested this using 1.0.65 distributed with my app with either 1.0.61 and/or 1.0.66 installed in the GAC.

In order to redirect the binding you simply need to modify your app's config file based on this information at http://msdn.microsoft.com/en-us/library/eftw1fys(VS.71).aspx

Here is an example that effectively redirects any version that SQLite.Linq might be looking for to 1.0.65:

<runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
                <dependentAssembly>
                        <assemblyIdentity name="System.Data.SQLite" culture="" publicKeyToken="db937bc2d44ff139"/>
                        <bindingRedirect oldVersion="1.0.0.0 - 2.0.0.0" newVersion="1.0.65.0"/>
                </dependentAssembly>
        </assemblyBinding>
</runtime>  

Hope you find this information helpful.

Sincerely,

Vincent Ugenti

Sr. Software Engineer

MiMedia LLC

www.mimedia.com

Thanks for the workaround. It looks like it should do the trick. I would still hope that future versions of SQLite have the Linq assembly versioned so that we don't have to add the binding redirect content to the config files of all our apps that are using our SQLite-dependent assembly.