Microsoft.Bcl.AsyncInterfaces missing for netcoreapp3.1

[AbeniMatteo]

Version

5.0.0

Expected behavior

No expection.

Actual behavior

Exception thrown:

An unhandled exception of type 'System.IO.FileNotFoundException' occurred in repro.dll
Could not load file or assembly 'Microsoft.Bcl.AsyncInterfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.

To Reproduce

repro.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="SimpleInjector" Version="5.0.0" />
  </ItemGroup>
</Project>

program.cs

namespace repro
{
    static class Program
    {
        static void Main() => LoadSimpleInjector();
        static void LoadSimpleInjector() => new SimpleInjector.Container();
    }
}

Additional context

For .NET Core apps, IAsyncDisposable is declared in System.Runtime.dll and Microsoft.Bcl.AsyncInterfaces is also not listed as a Nuget package dependency.

[dotnetjunkie]

Crap! I'm able to reproduce this issue. Not sure yet what goes wrong here. The NuGet references MS.Bcl.AsyncInterfaces in the 4.6.1 and .NETStandard2.0 targets. The reference is omitted in .NETStandard2.1 because the interface is part of .NETStandard2.1. But perhaps the version compiled for 2.1 contains a hard-referenece to MS.Bcl.AsyncInterfaces. I wil investigate and push a patch release.

In the meantime, you can work around the issue by adding MS.Bcl.AsyncInterfaces to your project as NuGet package.

[dotnetjunkie]

Problem found: the /lib/netstandard2.1/SimpleInjector.dll was missing from the NuGet package. This caused NuGet to revert to the /lib/netstandard2.0/SimpleInjector.dll, while still using the .NET Standard 2.1 configuration, which didn't include Microsoft.Bcl.AsyncInterfaces.

I pushed Simple Injector 5.0.1 to NuGet that fixes this problem.

[michaelkhalsa]

Hi,
App: Win Forms using .Net Framework 4.8
Installer: Microsoft VS Desktop Installer build .98
VS : 2019 Latest (not preview)

Build 5.01 (upgraded from build 4.1) broke my application (this took several days to find what was going on, as did not suspect simple injector). And adding a ref to nuget for this assembly does not work (I did not try an assembly redirect, and i believe i turned off this option).

It looks like Simple Injector contains a reference to 1.0.0 for Microsoft.Bcl.AsyncInterfaces
It will build fine and run within VS, however when installed, it crashes on startup with an error: reference assembly should only be loaded through reflection error.

I believe the solution is to use version 1.1.0 or 1.1.1 via nuget, as quite a few libraries do (such as csv helper, reactive, etc) within your library, instead of including a gac assembly in your library.

Downgrading back to simple injector 4.1 fixed the problem
This took several days of work to figure out.
Once i narrowed it down to Simple Injector as the culprit, I looked in the project assets.json file in the obj folder for the main windows project to go through all of the assemblies using the Bcl.AsyncInterfaces, and found that build 5.01 was indeed referencing 1.0.0 assembly. When i downgraded, the ref to any BCL assembly was gone from Simple Injector.

Several other libraries which are using version 1.1.0 work fine.

[dotnetjunkie]

Hi Michael,

A NuGet package should always use the lowest possible version of a dependency, which is why Simple Injector referwnces 1.0 of AsyncInterdaces. This generally means that binding redirects need to be used (under .NET) and NuGet typically managescthat for you. I say typically, because NuGet tends to fuck up from time to time.

But the solution is to manually add the binding redirect in case NuGet fails to do so.

[michaelkhalsa]

That’s true, except in this case. It started with value.tuples and the nightmare of conflicting namespaces and version conflicts, when moving from net 4.6.x to 4.7.2 Placing a redirect in the app.config worked some of the time. The best was not to have a nugget package and use the latest framework. Yet, some libraries wanted the nugget package. Microsoft tried to fix this with magic under the covers, but sometimes it did not work, and some areas were not aware of the magic. It was fragile when using VS package installer. One of the solutions included turning off package redirects for desktop apps. In this case ver 1.0.0 is a framework file. I am not sure if you are including the actual assembly in the package, but the error makes it sound like that? I traced how the manifest was being created for 4 different public libraries using bcl .asyncinterfaces, and simple injector was the one with the 1.0.0 ref, and caused the problems, which resolved when deleting the bin and obj folders and rebuilding with a version of simple injector wo this assembly. Try changing it to ver 1.1 Great product, and thank you for all of your work. Michael

[dotnetjunkie]

I am not sure if you are including the actual assembly in the package, but the error makes it sound like that?

No, no other dlls are included except the SimpleInjector.dll itself. The only thing the SimpleInjector.nupkg does is reference the other Nuget packages.

I'm very sorry you are running into this. It is for this exact reason that the Simple Injector core library never had any dependencies. You quickly run into binding redirect issues, and NuGet often fails to generate correct binding redirects for you.

Unfortunately, with The new IAsyncDisposable, there is no good way around this. You will have to add the binding redirect. Upgrading the package dependency might fix the problem for you, but is only a transient fix, because it will still cause problems for others and when never versions of AsyncInterfaces is pushed, as long as you don't use binding redirects under .NET Framework.

[michaelkhalsa]

Hi Steven,

I will circle around to this in a couple days, by creating a small test app, and see what works or not.

Including what happens when another library is present that is referencing version 1.1+ of Microsoft.BCL.AsyncInterfaces, along with Simple Injector 5.01

As well as revisit using an assembly redirection

Again, where it fails, is after installing the app with Microsoft Visual Studio Package Installer (upon startup), not after F5 build. So will test in that environment, to confirm the behavior in a limited small app.

On another note, you may want to contact the developers of the following libraries, to learn from their approach. All of these use Microsoft.BCL.AsyncInterfaces Ver 1.1.0

• System.Reactive
• CsvHelper
• Stripe.Net

Thanks, and will let you know if I find anything of value.

[dotnetjunkie]

You can add the following binding redirect to fix the problem:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
          <assemblyIdentity
              name="Microsoft.Bcl.AsyncInterfaces" publicKeyToken="cc7b13ffcd2ddd51" 
              culture="neutral" />
          <bindingRedirect oldVersion="0.0.0.0-{your-version}" newVersion="{your-version}"/>
        </dependentAssembly>
        <dependentAssembly>
          <assemblyIdentity
              name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" 
              culture="neutral" />
          <bindingRedirect oldVersion="0.0.0.0-{your-version}" newVersion="{your-version}"/>
        </dependentAssembly>
      </assemblyBinding>
    </runtime>
  </configuration>

Where {your-version} is the (highest) version you installed. Please note that you need to add the binding redirects for both Microsoft.Bcl.AsyncInterfaces and for System.Threading.Tasks.Extensions. For instance:

• Using Microsoft.Bcl.AsyncInterfaces 1.1.0:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
          <assemblyIdentity
              name="Microsoft.Bcl.AsyncInterfaces" publicKeyToken="cc7b13ffcd2ddd51" 
              culture="neutral" />
          <bindingRedirect oldVersion="0.0.0.0-1.1.0.0" newVersion="1.1.0.0" />
        </dependentAssembly>
        <dependentAssembly>
          <assemblyIdentity
              name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" 
              culture="neutral" />
          <!-- The 4.5.2 NuGet package contains an assembly with version 4.2.0.0 -->
          <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />
        </dependentAssembly>
      </assemblyBinding>
    </runtime>
  </configuration>

• Using Microsoft.Bcl.AsyncInterfaces 1.1.1:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
          <assemblyIdentity
              name="Microsoft.Bcl.AsyncInterfaces" publicKeyToken="cc7b13ffcd2ddd51" 
              culture="neutral" />
          <bindingRedirect oldVersion="0.0.0.0-1.1.1.0" newVersion="1.1.1.0" />
        </dependentAssembly>
        <dependentAssembly>
          <assemblyIdentity
              name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" 
              culture="neutral" />
          <!-- The 4.5.4 NuGet package contains an assembly with version 4.2.0.1 -->
          <bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
        </dependentAssembly>
      </assemblyBinding>
    </runtime>
  </configuration>

• Using Microsoft.Bcl.AsyncInterfaces 5.0.0:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
          <assemblyIdentity
              name="Microsoft.Bcl.AsyncInterfaces" publicKeyToken="cc7b13ffcd2ddd51" 
              culture="neutral" />
          <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
        </dependentAssembly>
        <dependentAssembly>
          <assemblyIdentity
              name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" 
              culture="neutral" />
          <!-- The 4.5.4 NuGet package contains an assembly with version 4.2.0.1 -->
          <bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
        </dependentAssembly>
      </assemblyBinding>
    </runtime>
  </configuration>

[andrejohansson]

I'm also hitting this problem and for me, binding redirects doesn't help. I cannot seem to figure out why.

I have the following setup

CodelockFunctionsNET (.net 461 target)
  -> BokaMera.Api.CodeLock.Model (netstandard2.0 target)
    -> Microsoft.Extensions.Logging 5.0.0
      -> Microsoft.Bcl.AsyncInterfaces
    -> SimpleInjector 5.1.0
      -> Microsoft.Bcl.AsyncInterfaces

I have tried a lot back and forth without any success. I get:

mscorlib: Exception while executing function: VanderbiltOmnis. CodeLockFunctionsNET: The type initializer for 'CodeLockFunctionsNET.DIConfig' threw an exception. CodeLockFunctionsNET: Could not load file or assembly 'Microsoft.Bcl.AsyncInterfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.

I have tried assembly redirects both via app.config and via setting

  <PropertyGroup>
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
  </PropertyGroup>

In both my projects: CodelockFunctionsNET and BokaMera.Api.CodeLock.Model.
When I look in my bin\Debug\net461 folder I find the generated binding redirects correctly:

Also the file is present and is v5.0.0.0

Then I start the project using func host start (this is a Azure Function v1), and as soon as it should load SimpleInjector I get the exception.

Not that ILogger from Microsoft.Extensions.Logging who also uses Microsoft.Bcl.AsyncInterfaces can be present and works.

Commenting out all SimpleInjector code makes the code run without exceptions.

So...something is fishy here still unfortunately, it´s like the redirect is not respected at all?

Any suggestions of how I can proceed?

[andrejohansson]

Follow up: Apparently, binding redirects does not exist on Azure functions! But the solution presented in this article seems to work for me: https://www.thewissen.io/azure-functions-binding-redirects/