2

When running BenchmarkDotNet for a method in my project I get a few "Wrong assembly binding redirect" warning/error messages printed to screen. This got me a bit puzzled, as I thought assembly binding redirects is a .Net Framework concept, while my projects are .Net Core 3.0. Googling the warning/error message gave no result. Any tips to what these messages mean, and possibly how to fix the problem. I tried cleaning Nuget cache, restoring Nuget packages, cleaning and rebuilding the solution, but to no help.

// BeforeAnythingElse

// Benchmark Process Environment Information:
// Runtime=.NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT
// GC=Concurrent Workstation
// Job: DefaultJob

OverheadJitting  1: 1 op, 308100.00 ns, 308.1000 us/op
// Wrong assembly binding redirects for System.Data.Common.resources, Version=4.2.1.0, Culture=en-US, PublicKeyToken=b03f5f7f11d50a3a.
// Wrong assembly binding redirects for System.Data.Common.resources, Version=4.2.1.0, Culture=en, PublicKeyToken=b03f5f7f11d50a3a.
// Wrong assembly binding redirects for System.Data.SqlClient.resources, Version=4.6.0.0, Culture=en-US, PublicKeyToken=b03f5f7f11d50a3a.
// Wrong assembly binding redirects for System.Data.SqlClient.resources, Version=4.6.0.0, Culture=en, PublicKeyToken=b03f5f7f11d50a3a.
// Wrong assembly binding redirects for System.Private.Xml.resources, Version=4.0.1.0, Culture=en-US, PublicKeyToken=cc7b13ffcd2ddd51.
// Wrong assembly binding redirects for System.Private.Xml.resources, Version=4.0.1.0, Culture=en, PublicKeyToken=cc7b13ffcd2ddd51.
Petter T
  • 3,387
  • 2
  • 19
  • 31

1 Answers1

7

The short answer is that you can ignore this warning.

The long answer: for some reason VS sometimes generates invalid assembly binding redirects for Full .NET Framework projects that reference .NET Standard libraries. It was causing a lot of trouble to BenchmarkDotNet users in the past:

I decided to implement an ugly workaround that searches for .dll file manually and loads it when .NET Framework fails to do so.

Of course, this applies only to Full .NET Framework. When I was porting BenchmarkDotNet to .NET Standard 2.0 I've forgotten that we don't need to do this for .NET Core. As the end result, you get this confusing warning.

I've sent a PR that fixes that: https://github.com/dotnet/BenchmarkDotNet/pull/1365 and this workaround will now be executed only for Full .NET Framework projects

Adam Sitnik
  • 1,256
  • 11
  • 15