System.Data.SQLite

The version of the DLL included in the package System.Data.SQLite.Core version 1.0.112.2 is actually 1.0.112.1.

Visual Studio automatically creates assembly redirects in my config files as follows:

<dependentAssembly>
        <assemblyIdentity name="System.Data.SQLite" publicKeyToken="db937bc2d44ff139" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-1.0.112.2" newVersion="1.0.112.2" />
      </dependentAssembly>

This causes the .Net Framework (I'm using 4.6.2) to try and load the assembly with version 1.0.112.2 from the package, resulting in the following exception: Could not load file or assembly 'System.Data.SQLite, Version=1.0.112.2, Culture=neutral, PublicKeyToken=db937bc2d44ff139' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

With InnerException: Could not load file or assembly 'System.Data.SQLite, Version=1.0.112.1, Culture=neutral, PublicKeyToken=db937bc2d44ff139' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

In the Fusion log I saw: LOG: Redirect found in application configuration file: 1.0.112.1 redirected to 1.0.112.2.

Which pointed me in the direction of the following workaround: <bindingRedirect oldVersion="0.0.0.0-1.0.112.2" newVersion="1.0.112.1" />

This results in a working situation.

I'm not sure if it was intended not to change the assembly version with the package version, but I think updating it would have prevented this issue.

This is by design.  The source code was not changed between release 1.0.112.1
and 1.0.112.2.  Only the NuGet packages were changed.

I have not seen the issue with Visual Studio using binding redirects before;
however, it seems like an issue specific to Visual Studio, i.e. as far as I
know, there is no requirement for a NuGet package version to exactly match
that of the managed assemblies contained within it.