System.Data.SQLite

Login
This project makes use of Eagle, provided by Mistachkin Systems.
Eagle: Secure Software Automation
Ticket Hash: c342197be6ac2cae4e8a3283a8fc66334266a30d
Title: DLL version in package 1.0.112.2 is still 1.0.112.1
Status: Closed Type: Incident
Severity: Important Priority: Medium
Subsystem: NuGetPackage Resolution: External_Bug
Last Modified: 2020-10-29 02:30:14
Version Found In: 1.0.112.2
User Comments:
anonymous added on 2020-05-08 07:13:34: (text/x-markdown)
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: 
      ```xml
<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.

mistachkin added on 2020-05-23 23:52:51: (text/x-fossil-plain)
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.