Csvhelper: Reference mismatch to System.Threading.Tasks.Extensions

[mtissington]

Using 4.7.2

Not sure when this started but now we are getting the following and can no longer import any file.

`System.IO.FileLoadException: Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

File name: 'System.Threading.Tasks.Extensions, Version=4.2.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' ---> System.IO.FileLoadException: Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

File name: 'System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'

WRN: Assembly binding logging is turned OFF.

To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.

Note: There is some performance penalty associated with assembly bind failure logging.

To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

at CsvHelper.Configuration.CsvConfiguration..ctor(CultureInfo cultureInfo)`

[mtissington]

Resolved - seems to have a dependency on nuget Microsoft System.Threading.Tasks.Extensions

[JoshClose]

NuGet should add that for you. What version of CsvHelper?

[mtissington]

That's what I thought - I'm using the latest version of CsvHelper and needed to add the Extensions manually.

[JoshClose]

That's included for the 4.7 build. Maybe it's a fluke?

https://github.com/JoshClose/CsvHelper/blob/24d8d5393d1c88f852fec32803419bf5a800f2b9/src/CsvHelper/CsvHelper.csproj#L50

[mtissington]

Hmm, i know it should but will it work for 4.7.2 also?

On Mar 28, 2020, at 15:32, Josh Close [e-mail] wrote:


That's included for the 4.7 build. Maybe it's a fluke?

https://github.com/JoshClose/CsvHelper/blob/24d8d5393d1c88f852fec32803419bf5a800f2b9/src/CsvHelper/CsvHelper.csproj#L50

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[donovan-ecargo]

I'm experiencing the same issue.

Last working version is 13.0.0 for me, with 4.7.2 .net as the framework. It is also the last one without the dependency on System.Threading.Tasks.Extensions.

My guess is that it's something going wrong with the dependency definition for the package

[imm-olate]

I had the same issue running CsvHelper 15.0.5, it seemed to be an incompatibility with System.Text.Json 4.7.2 (may have been 4.7.1). I had to downgrade System.Text.Json to 4.6.0.

[chucklu]

I had the same issue but not using CsvHelper, I believed it can be fixed by the same solution. ProjectA referenced a custom libraryB.
I just checked the version of System.Threading.Tasks.Extensions under bin folder, find it's with the wrong verison 4.2.0.0.
Then I tried to scan the dependencies of my bin folder, check which *.exe or *.dll depend on System.Threading.Tasks.Extensions, and print the library and the version of System.Threading.Tasks.Extensions
1
Microsoft.Bcl.AsyncInterfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51

2
System.Text.Json, Version=4.0.1.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51

The above two libraries was used by libraryB, and when I check the nuget libraries list, I find libraryB depends on System.Threading.Tasks.Extensions with nuget version 4.5.4, which assembly version is 4.2.0.1

My solution is manually add System.Threading.Tasks.Extensions nuget reference with nuget version 4.5.4 in ProjectA directly.

[chucklu]

And you will encounter another similar issue， which report the wrong version for "System.Runtime.CompilerServices.Unsafe", it's required 4.0.6.0 version, which mapped to nuget version 4.7.0.
The solution is manually add System.Runtime.CompilerServices.Unsafe nuget reference with nuget version 4.7.0 in ProjectA directly.
https://stackoverflow.com/a/62770487/13338936
1
Microsoft.Extensions.Primitives, Version=3.1.6.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
System.Runtime.CompilerServices.Unsafe, Version=4.0.6.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

2
System.Memory, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

3
System.Text.Json, Version=4.0.1.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
System.Runtime.CompilerServices.Unsafe, Version=4.0.6.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

4
System.Threading.Tasks.Extensions, Version=4.2.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

[chucklu]

In conclusion, add the following two packages in Project directly(the project which reported the mismatch problem)

     <package id="System.Runtime.CompilerServices.Unsafe" version="4.7.0" targetFramework="net472" />
     <package id="System.Threading.Tasks.Extensions" version="4.5.4" targetFramework="net472" />

And the nuget should add the following bindingRedirect for you automatically in config file

   <dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.6.0" newVersion="4.0.6.0" />
      </dependentAssembly>
 <dependentAssembly>
       <assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
       <bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
      </dependentAssembly>

[JoshClose]

There is another issue for this. Does this help? https://github.com/JoshClose/CsvHelper/issues/1462

[chrishildebran]

@JoshClose, last week I had success employing a solution @MikeYeager suggested in issue #1462 (Closed), but today I'm yet again bit by this reference roundy-round. I've tried three times to replicate his solution with CSV v16, but it just keeps failing. I've tried to make heads or tails of what the answer is, specifically @chucklu's, but I'm just spinning. Is there a bottom-line solution to this that will allow me to release with confidence?

[chucklu]

@chrishildebran Where did you encounter this issue?
1.on developed environment(local machine)？ You can provide me a repository which can reproduce it.
2.on deploy environment(test, staging, production)?
3.And what's the exact error info you got?
By the way, I did not have experience about Azure.

[chrishildebran]

@chucklu, im seeing this error during debuggin in Visual Studio. Cannot provide code. See attached collage of screenshots.

[chrishildebran]

I will say that reverting to a previously release's package config (CSV Helper 15.0.5, Microsoft.BCL.AsyncInterfaces 1.1.0, and System.Threading.Task.Extensions 4.5.2 is working. It would be nice to be able to upgrade without worrying though.

[chucklu]

@chrishildebran Please configure your visual studio, Tools-->Options-->Projects and Solutions-->Build And Run
Then set the output verbosity to detailed, rebuild your solution, then copy the ouput log and save it as a file, and upload it here.

If it's possible, could you zip your bin folder with the dll files and upload it here, I would like to analysis the dependency of all dll files.

[chucklu]

im seeing this error during debuggin in Visual Studio

Did you mean when you run the application directly, there is no problem? Then I guess it should be the problem of visual studio

[chucklu]

@JoshClose I find another version mismatch issue https://github.com/NuGet/Home/issues/10302, and it might be bug of nuget.
If nuget does not support auto detection feature, then we need to manually fix these issues.