Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Azure Key Vault: Could not load file or assembly System.Buffers

See original GitHub issue

Trying to get a secret from Azure Key Vault and I’m getting this exception on client.GetSecretAsync(string) in a .NET Framework 4.7.1 C# project.

Azure.Identity.AuthenticationFailedException HResult=0x80131500 Message=ClientSecretCredential authentication failed. Source=Azure.Identity StackTrace: at Azure.Identity.ClientSecretCredential.<GetTokenAsync>d__16.MoveNext() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Azure.Security.KeyVault.ChallengeBasedAuthenticationPolicy.<AuthenticateRequestAsync>d__9.MoveNext() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Azure.Security.KeyVault.ChallengeBasedAuthenticationPolicy.<ProcessCoreAsync>d__8.MoveNext() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Threading.Tasks.ValueTask.ThrowIfCompletedUnsuccessfully() at Azure.Core.Pipeline.RetryPolicy.<ProcessAsync>d__11.MoveNext() at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at Azure.Core.Pipeline.RetryPolicy.<ProcessAsync>d__11.MoveNext() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Azure.Core.Pipeline.HttpPipelineSynchronousPolicy.<ProcessAsync>d__1.MoveNext() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Azure.Core.Pipeline.HttpPipelineSynchronousPolicy.<ProcessAsync>d__1.MoveNext() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Azure.Core.Pipeline.HttpPipeline.<SendRequestAsync>d__10.MoveNext() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Azure.Security.KeyVault.KeyVaultPipeline.<SendRequestAsync>d__27.MoveNext() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Azure.Security.KeyVault.KeyVaultPipeline.<SendRequestAsync>d__211.MoveNext() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Azure.Security.KeyVault.Secrets.SecretClient.<GetSecretAsync>d__8.MoveNext() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter1.GetResult() at Common.AzureSettings.<LoadJsonFromAzure>d__2.MoveNext() in C:\Builds\ebms-2XX\ebms-234-dev\ebms\EbmsServices\Common\AzureSettings.cs:line 43

Inner Exception 1: AggregateException: Retry failed after 4 tries.

Inner Exception 2: RequestFailedException: Error while copying content to a stream.

Inner Exception 3: HttpRequestException: Error while copying content to a stream.

Inner Exception 4: FileLoadException: Could not load file or assembly ‘System.Buffers, Version=4.0.2.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)

Fusion log from the first try

=== Pre-bind state information === LOG: DisplayName = System.Buffers, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 (Fully-specified) LOG: Appbase = file:///C:/Builds/ebms-2XX/ebms-234-dev/ebms/EBMSServerManager/Tests/EBMSServerManagerLibraryTests/bin/x86/Debug LOG: Initial PrivatePath = NULL Calling assembly : Azure.Core, Version=1.0.2.0, Culture=neutral, PublicKeyToken=92742159e12e44c8. === LOG: This bind starts in default load context. LOG: Using application configuration file: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\Extensions\TestPlatform\testhost.x86.exe.Config LOG: Using host configuration file: LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config. LOG: Post-policy reference: System.Buffers, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 LOG: Attempting download of new URL file:///C:/Builds/ebms-2XX/ebms-234-dev/ebms/EBMSServerManager/Tests/EBMSServerManagerLibraryTests/bin/x86/Debug/System.Buffers.DLL. WRN: Comparing the assembly name resulted in the mismatch: Build Number ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

Issue Analytics

State:
Created 3 years ago
Comments:13 (4 by maintainers)

Top GitHub Comments

3reactions

joperezrcommented, Apr 8, 2020

While I haven’t looked at the repro yet, this does in deed seem to be a problem with a missing binding redirect. When using test projects, it might be tricky as I believe that by default we only generate binding redirects for projects that produce *.exe, and not for dlls. To me this looks like the case where two different assemblies in your closure need System.Buffers, one needs the 4.0.2.0 version but another one depends on a newer package so it is bumping the dependency up to the 4.0.3 one which is the one that ends up in your ouptut folder. During execution, if you don’t have a binding redirect telling the assembly that depends on 4.0.2 version that it should just load 4.0.3, you will hit the exception you are hitting. I believe testhost.x86 is one of those test hosts that will take into account dll.config files when loading assemblies, so would you mind adding the following to your projects in order to force msbuild to produce a dll.config for you?:

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

2reactions

joperezrcommented, Apr 8, 2020

Glad to hear that worked for you. I totally agree with this not being intuitive, and I would suggest logging an issue on the https://github.com/dotnet/sdk or the https://github.com/Microsoft/MSBuild repos in order to make it such that projects that don’t have an .exe output type will also be considered (which is the case for test projects and also for some ASP.NET projects). They would really be the experts that could make this scenario better.