Error loading System.Threading.Tasks.Extensions (on version 15)

[mikeTWC1984]

I'm trying to create some netstandard2.0 class library using CsvHelper, and consume it with PowerShell. Everything works with CsvHelper 13. Version 14/15 work with PowerShell Core (based on .net core 3.1), but getting error below if using with Windows Powershell (using 4.8 framework).

Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral,
PublicKeyToken=cc7b13ffcd2ddd51'

Since it works with version 13, hopefully there is some easy fix

[JoshClose]

What version of CsvHelper is used when using framework 4.8?

[JoshClose]

CsvHelper has it listed for everything before netstandard2.1, but it's version 4.5.3, not 4.2.0.

<!-- .NET 4.5 -->
<ItemGroup Condition="'$(TargetFramework)' == 'net45'">
	<PackageReference Include="Microsoft.CSharp" Version="4.5.0" />
	<PackageReference Include="System.Threading.Tasks.Extensions" Version="4.5.3" />
	<PackageReference Include="System.ValueTuple" Version="4.4.0" />
</ItemGroup>

<!-- .NET 4.7 -->
<ItemGroup Condition="'$(TargetFramework)' == 'net47'">
	<PackageReference Include="Microsoft.Bcl.AsyncInterfaces" Version="1.1.0" />
	<PackageReference Include="Microsoft.CSharp" Version="4.5.0" />
	<PackageReference Include="System.Threading.Tasks.Extensions" Version="4.5.3" />
</ItemGroup>

<!-- .NET Standard 2.0 -->
<ItemGroup Condition="'$(TargetFramework)' == 'netstandard2.0'">
	<PackageReference Include="Microsoft.Bcl.AsyncInterfaces" Version="1.1.0" />
	<PackageReference Include="Microsoft.CSharp" Version="4.5.0" />
	<PackageReference Include="System.Threading.Tasks.Extensions" Version="4.5.3" />
</ItemGroup>

<!-- .NET Standard 2.1 -->
<ItemGroup Condition="'$(TargetFramework)' == 'netstandard2.1'">
	<PackageReference Include="Microsoft.CSharp" Version="4.5.0" />
</ItemGroup>

[mikeTWC1984]

I'm getting this error with CsvHelper 15 and 14 (netstandard2.0). I tried it on different machine that uses 4.7, getting same error. Those are versions that has Tasks.Extensions as dependency. v13 doesn't have direct dependency on Tasks.Extensions, but Bcl requires it too. Maybe this is because Bcl and CsvHelper refer to different version of Task.Extension? I haven't tested it on actual net framework app (only on core), so this also could be some powershell specific thing.

[JoshClose]

Maybe it's related to this dotnet/runtime#10674

Can you see if that workaround works in your scenario?

[mikeTWC1984]

Turns out this is because different version indeed. I tried to build CsvHelper from source downgrading Tasks.Extensions to 4.5.2 and then was able to load it. If I keep 4.5.3 still getting same error.

[JoshClose]

Can you try the MyApp.deps.json workaround? For whatever reason when you're running in PowerShell it doesn't want to use that version.

[mikeTWC1984]

OK, will try. They seemed to apply this to .net core console app, however in my case netcore console works fine

[JoshClose]

I think I misunderstood something. I'll take a closer look.

[JoshClose]

For some reason I though you were writing something that worked with PowerShell, and not just running a console app through PowerShell.

[mikeTWC1984]

OK. I suspect there might be an issue loading netstandard CsvHelper to netframework project

[JoshClose]

If you reference CsvHelper net47 instead of netstandard2.0, does it work?

[mikeTWC1984]

Same. I realized it's more like an issue with Microsoft.Bcl.AsyncInterfaces. Somehow it doesn't like Tasks.Extensions 4.5.3, at least within windows powershell runtime (4.x). Wondering if regular netframework app can handle it, will try to test it later

[mikeTWC1984]

It seemed to be a global issue, not just powershell. Just tried to create net47 console app and getting same error. net45 works, but it has no dependency on Bcl. I guess we need to downgrade Tasks.Extensions to 4.5.2. for Net47 and NetStandard, unless there is some better solution.

[mikeTWC1984]

I opened an issue with corefx, we'll see what they say

[cwhsu1984]

My target framework is 472, and I get the same issue here.

Installing CsvHelper 15.0.0, but keep getting the below errors

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)

Initially, I thought it was because of the Microsoft.Bcl.AsyncInterfaces which I get one with 1.0.0, but after upgrading to 1.1.0. I'm still having the same error, and I upgrade all the System.Threading.Tasks.Extensions to 4.5.3.

And from nuget package manager, I should be able to use Microsoft.Bcl.AsyncInterfaces 1.1.0 with System.Threading.Tasks.Extensions to 4.5.3. However, I keep getting the same error.

From the Fusion log, it shows this.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable  c:\windows\system32\inetsrv\w3wp.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: DisplayName = System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
 (Fully-specified)
LOG: Appbase = file:///F:/myproject/
LOG: Initial PrivatePath = F:\myproject\bin
Calling assembly : Microsoft.Bcl.AsyncInterfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: F:\myproject\web.config
LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/d0496855/5ee4f0fd/System.Threading.Tasks.Extensions.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/d0496855/5ee4f0fd/System.Threading.Tasks.Extensions/System.Threading.Tasks.Extensions.DLL.
LOG: Attempting download of new URL file:///F:/myproject/bin/System.Threading.Tasks.Extensions.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

I already spend a day fixing this. I think I'll try downgrade the CsvHelper now.

[cwhsu1984]

In the end, I downgrade to 14.0.0 to fix the issue

[Jaans]

Same problem for us. We are targetting .NET Framework 4.8 and get assembly load failures at runtime when dynamically loading in assemblies into IoC container.

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)

Looking at the assembly references in DotPeek, it looks like CsvHelper has a reference to System.Threading.Tasks.Extension v4.2.0.1 but Microsoft.Bcl.AsyncInterfaces (which CsvHelper started referencing since >= v13) has itself a reference to System.Threading.Tasks.Extension v4.2.0.0

Refer screenshot:

[JoshClose]

I just pushed 15.0.1 to NuGet which has System.Threading.Tasks.Extensions downgraded to 4.5.2 which should hopefully solve this. Let me know when you try it.

[mikeTWC1984]

It works now

[JoshClose]

@mikeTWC1984 Do you have a link to your issue with CoreFX?

[mikeTWC1984]

dotnet/runtime#32797

[DaveInCaz]

I think this is the issue mentioned in https://stackoverflow.com/questions/60194368/could-not-load-file-or-assembly-system-threading-tasks-extensions-version-4-2

[DaveInCaz]

FWIW downgrading to 13.0 also worked around this, and without any code changes to the code I had previously written to use 15.0.

[Methuselah96]

Now with 15.0.1 I'm getting a runtime error:

System.IO.FileNotFoundException : 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 system cannot find the file specified.
  ----> System.IO.FileNotFoundException : 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 system cannot find the file specified.

I wasn't getting this with 15.0.0. This is for .NET Framework 4.7.

[JoshClose]

@Methuselah96 What is trying to use 4.2.0.1?

[Methuselah96]

@JoshClose Here is the output of Fuslogvw.exe:

*** Assembly Binder Log Entry  (3/10/2020 @ 12:37:12 PM) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable  C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\Extensions\TestPlatform\testhost.x86.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: DisplayName = System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
 (Fully-specified)
LOG: Appbase = file:///C:/Users/ParagonUser/Documents/Project/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = Tests_1718425640
Calling assembly : Microsoft.Bcl.AsyncInterfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Users\ParagonUser\Documents\Project\bin\Debug\Project.dll.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Redirect found in application configuration file: 4.2.0.0 redirected to 4.2.0.1.
LOG: Post-policy reference: System.Threading.Tasks.Extensions, Version=4.2.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/Users/ParagonUser/Documents/Project/bin/Debug/System.Threading.Tasks.Extensions.DLL.
LOG: Attempting download of new URL file:///C:/Users/ParagonUser/Documents/Project/bin/Debug/System.Threading.Tasks.Extensions/System.Threading.Tasks.Extensions.DLL.
LOG: Attempting download of new URL file:///C:/Users/ParagonUser/Documents/Project/bin/Debug/System.Threading.Tasks.Extensions.EXE.
LOG: Attempting download of new URL file:///C:/Users/ParagonUser/Documents/Project/bin/Debug/System.Threading.Tasks.Extensions/System.Threading.Tasks.Extensions.EXE.
LOG: All probing URLs attempted and failed.

[JoshClose]

Do you have this redirect in your config file?

LOG: Redirect found in application configuration file: 4.2.0.0 redirected to 4.2.0.1.

[JoshClose]

That's a cool tool though. I haven't used that one before.

[Methuselah96]

I figured it out. The binding redirect was correct, but I just had forgotten to install a transitive dependency in my test project. I'm not sure why that would give me that specific error message with 15.0.1, but not 15.0.0, but it doesn't matter. All good, sorry to bother you.

And, yeah, that tool is the only thing that provides sanity in the world of C# assemblies.

[DaveInCaz]

@Methuselah96 would you mind sharing the details of what you meant by transitive dependency? What did you actually have to change in your project? Thanks!

[Methuselah96]

@DaveInCaz I had ProjectA and ProjectA.Tests (.NET Framework). ProjectA had the NuGet package CsvHelper installed, but ProjectA.Tests did not.

Again, I'm not sure how it worked before 15.0.0 -> 15.0.1, since ProjectA.Tests needs to have all the dependencies that ProjectA has. But installing CsvHelper in ProjectA.Tests fixed it for me.

[amittyyy]

Simple and short Answer:-

Make sure your EFCore installed version and EF related Other NuGet packages have same version.

Like:- EFCore v5.0.0 Preview 3.2.....
Than all packages has same version.
Like:- EFCore.Sql

Hope this will help you,

[MikeYeager]

We just spent a morning working through this issue. In our case, both of our Dev machines ran fine, but we got the error when our CI/CD build deployed to Azure. There we found that System.Threading.Tasks.Extensions.dll was truly not being deployed to the bin folder on the web site. The file did exist in our local bin folders. In our situation, the reference was in one assembly and that project was referenced in the web site project being deployed. We removed the NuGet packages for CsvHelper, Microsoft.Bcl.AsyncInterfaces and System.Threading.Task.Exensions. We then went through every project in the solution and removed any left over binding redirects and verified that every package.config file had no references to any of the packages. Then we shut down Visual Studio, deleted all of the bin and obj folders from all of the projects and removed any left over packages from the packages folder. We then re-started VS, re-installed CsvHelper 15.0.0, did a local build, verified it was correct, then checked it in for a new CD/CI deployment. Lo and behold, the .dll was copied to the web site! I can't say why it worked. The NuGeet package version for System.Threading.Tasks that got installed is 4.5.4. If you right click on the properties for the file, it says it's 4.2.01. If you track down the file based on the path in the properties window or look in the bin folder and check the file properties, it's 4.6.28619.1. Go Figure. If you run into this problem, I recommend looking in your bin folder for that file. If it's not there, you know why you get the exception. What it doesn't tell you is why the file isn't there.

[tscilipoti]

THANK YOU, @MikeYeager

We removed the NuGet packages for CsvHelper, Microsoft.Bcl.AsyncInterfaces and System.Threading.Task.Exensions. We then went through every project in the solution and removed any left over binding redirects and verified that every package.config file had no references to any of the packages. Then we shut down Visual Studio, deleted all of the bin and obj folders from all of the projects and removed any left over packages from the packages folder. We then re-started VS, re-installed CsvHelper 15.0.0, did a local build...

[pvg8v6g]

I also have this bug and have no idea what I need to solve this. I'm NOT downgrading System.Threading.Tasks.Extensions.

The version I have on that is 4.2.0.0 and the error says:

Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.1,

Really have no idea what to do here.

[lieven-alundi]

For anyone still experiencing this error. I fixed it by also updating the Microsoft.Bcl package to the latest version (1.1.10). Make sure to have the most recent versions of Microsoft.Bcl.AsyncInterfaces & Microsoft.Bcl.Build as well. Microsoft.Bcl.AsyncInterfaces has a dependency on System.Threading.Tasks.Extensions.

[chucklu]

@pvg8v6g If you can provide a sample repository that can reproduce the same issue, I would like to troubleshooting for you.

[chrishildebran]

Steps taken by @MikeYeager worked for me too.

[chucklu]

encounter the same problem again, and tried withUpdate-Package System.Threading.Tasks.Extensions -r fix the problem.
It seems even a class library need a app.config with assembly bindingRedirect in it.

[chucklu]

A little difference from my experience, we encounter this problem in web site project.
We manually add System.Threading.Tasks.Extensions.dll.refresh under the bin folder, and set the correct path for the library, then it works.

[JoshClose]

Does anyone see a change that can be made in CsvHelper to fix this, or is it just an issue within Microsoft/Visual Studio?

[chucklu]

The question would be, did CsvHelper really depends on System.Threading.Tasks.Extensions.dll?
When I remove the dependency from net47, the project build successfully. Why you add the dependency manually?
https://github.com/JoshClose/CsvHelper/blob/master/src/CsvHelper/CsvHelper.csproj#L49

When I check the output folder(build project without dependency of ), and check the dependency, I find both CsvHelper and Microsoft.Bcl.AsyncInterfaces depend on System.Threading.Tasks.Extensions. This is weird, since I have removed the dependency of System.Threading.Tasks.Extensions for CsvHelper.
CsvHelper, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8c4959082be5c823
System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51

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

[chucklu]

@JoshClose Just found you have released CsHelper 16.0, https://www.nuget.org/packages/CsvHelper/16.0.0
And it's weird that you add dependency System.Threading.Tasks.Extensions (>= 4.5.2) for net47, since your library actually did not depend on it(from code level, the weird thing is the compiled .dll file has dependency when view by dnSpy)

Actually Microsoft.Bcl.AsyncInterfaces 1.1.0 has dependency of System.Threading.Tasks.Extensions (>= 4.5.2) for net461. And you only need to specify Microsoft.Bcl.AsyncInterfaces (>= 1.1.0), from my experience I believe the nuget install will handle the dependency automatically for users.

[chucklu]

The only thing we need to figure out here is, when removed the dependency System.Threading.Tasks.Extensions from net47, the project build successfully, Why the compiled the dll file has a dependency of System.Threading.Tasks.Extensions?
I will file a bug report on visual studio forum later for this.

[chucklu]

It seems the CsvHelper depends on System.Threading.Tasks.Extensions for ValueTask. And even if I removed System.Threading.Tasks.Extensions dependency from net47, visual studio did not report error, something wrong here, might a bug of visual studio.
https://github.com/JoshClose/CsvHelper/blob/master/src/CsvHelper/CsvSerializer.cs#L164

[chucklu]

@JoshClose Finally there should be no problem caused by CsvHelper, when they encounter, they just need to check the bindingRedirect in their config file. You can close this issue. Ask them to file new issue with a reproduce repository next time, and I would like to do the troubleshooting.

[JoshClose]

@chucklu Thanks.

[kvillines]

I am still getting this issue in the latest version of CsvHelper 18.... I have tried every stated above and nothing helps. The only thing I haven't tried is downgrading CsvHelper.

=== Pre-bind state information ===
LOG: DisplayName = System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
(Fully-specified)
LOG: Appbase = file:///C:/Users/Kvillines/Source/Repos/LCRM/Src/UnitTests/HPO.SERVICE.Processes.Tests/bin/Debug
LOG: Initial PrivatePath = NULL
Calling assembly : Microsoft.Bcl.AsyncInterfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51.

LOG: This bind starts in LoadFrom load context.
WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().
LOG: Using application configuration file: C:\Users\Kvillines\Source\Repos\LCRM\Src\UnitTests\HPO.SERVICE.Processes.Tests\bin\Debug\HPO.LIB.Processes.Tests.dll.config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Redirect found in application configuration file: 4.2.0.0 redirected to 4.5.4.0.
LOG: Post-policy reference: System.Threading.Tasks.Extensions, Version=4.5.4.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
LOG: Attempting download of new URL file:///C:/Users/Kvillines/Source/Repos/LCRM/Src/UnitTests/HPO.SERVICE.Processes.Tests/bin/Debug/System.Threading.Tasks.Extensions.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
LOG: Attempting download of new URL file:///C:/Users/Kvillines/Source/Repos/LCRM/Src/UnitTests/HPO.SERVICE.Processes.Tests/bin/Debug/System.Threading.Tasks.Extensions/System.Threading.Tasks.Extensions.DLL.
LOG: Attempting download of new URL file:///C:/Users/Kvillines/Source/Repos/LCRM/Src/UnitTests/HPO.SERVICE.Processes.Tests/bin/Debug/System.Threading.Tasks.Extensions.EXE.
LOG: Attempting download of new URL file:///C:/Users/Kvillines/Source/Repos/LCRM/Src/UnitTests/HPO.SERVICE.Processes.Tests/bin/Debug/System.Threading.Tasks.Extensions/System.Threading.Tasks.Extensions.EXE.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/Common7/IDE/PublicAssemblies/System.Threading.Tasks.Extensions.DLL.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/Common7/IDE/PublicAssemblies/System.Threading.Tasks.Extensions/System.Threading.Tasks.Extensions.DLL.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/Common7/IDE/PublicAssemblies/System.Threading.Tasks.Extensions.EXE.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/Common7/IDE/PublicAssemblies/System.Threading.Tasks.Extensions/System.Threading.Tasks.Extensions.EXE.

[Methuselah96]

LOG: Redirect found in application configuration file: 4.2.0.0 redirected to 4.5.4.0.

@kvillines Looks like you might have an app.config? Try fixing the redirect in that file.

[kvillines]

@Methuselah96 I added the redirect to try and fix the issue. The project builds fine but at runtime it tries to load 4.2.0.0 of the assembly. I have the latest assembly from NuGet which is 4.5.4.

I just pulled out the redirect and it didn't matter. I might just build a unit test project from scratch and see if I can make it work.

[Methuselah96]

@kvillines The NuGet version number is not the same as the version in the binding redirects. Try 4.2.0.1 instead.

[kvillines]

@Methuselah96 oh, so the version it shows me in the csproj file isn't really the correct one?

[Methuselah96]

@kvillines Correct, the version in the csproj is the NuGet package version. The version in the binding redirects is the assembly version. Here's some documentation on the difference: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/versioning.

[kvillines]

@Methuselah96 that worked!! Thank you very much.

[TimMakins]

Hoping this message will help someone who see it..
June 2023 with CSVHelper 30.0.1

I was still getting the message:
System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Bcl.AsyncInterfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies.
after I deployed the application to a new computer.

I had tried the full routine mentioned by @tscilipoti above - made no difference.
One thing that others here had not mentioned:
After installing CsvHelper 30.0.1, Updates were flagged as required in the NuGet Package Manager:
Microsoft.Bcl.AsyncInterfaces from 1.0.0 to 8.0.0-preview.5.23280.8
Microsoft.Bcl.HashCode from 1.0.0 to 1.1.1
System.Threading.Tasks.Extensions from 4.5.2 to 4.5.4
I updated all these.

Built and deployed the program, and got the message:

System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Bcl.AsyncInterfaces, Version=1.0.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: 'Microsoft.Bcl.AsyncInterfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'

So, in the 'runtime' section of my 'App.config' file, which was included in my InnoSetup installer, I changed :

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Bcl.AsyncInterfaces" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
  </dependentAssembly>

to

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Bcl.AsyncInterfaces" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="8.0.0.0" />
  </dependentAssembly>

And it all worked!