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:

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.


mistachkin added on 2020-05-23 23:52:51:
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.