Runtime: .NET 4.7.1 app experiences unexpected "Could not load file or assembly 'System.Runtime, Version=4.1.2.0"

Created on 11 Oct 2018 · 13Comments · Source: dotnet/runtime

Create a new .NET Framework 4.7.1 console app project.
Install BenchmarkDotNet NuGet package with DependencyBehavior=Highest.
Paste the following code into Program.cs and excute the app as Release build.

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

namespace ConsoleApp3
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            BenchmarkRunner.Run<Foo>();
        }
    }

    [ClrJob]
    public class Foo
    {
        [Benchmark]
        public void Bar()
        {

        }
    }
}

Expected result: app executes and does some no-op benchmarks.

Actual result:

// Validating benchmarks:
// ***** BenchmarkRunner: Start   *****
// ***** Building 1 exe(s) in Parallel: Start   *****
// ***** Done, took 00:00:00 (0.13 sec)   *****
// Found benchmarks:
//   Foo.Bar: Clr(Runtime=Clr)

// Build Exception: Could not load file or assembly 'System.Runtime, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Packages.config contains this:

<package id="System.Runtime" version="4.3.0" targetFramework="net471" />

App.config contains this:

<dependentAssembly>
        <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.1.2.0" />
      </dependentAssembly>

Inspecting what is happening with a debugger indicates that the exception occurs in the cctor of the Builder class:

Unhandled Exception: System.TypeInitializationException: The type initializer for 'BenchmarkDotNet.Toolchains.Roslyn.RoslynToolchain' threw an exception. ---> System.TypeInitializationException: The type initializer for 'BenchmarkDotNet.Toolchains.Roslyn.Builder' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.0.20.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
   --- End of inner exception stack trace ---
   at BenchmarkDotNet.Toolchains.Roslyn.Builder..cctor()
   --- End of inner exception stack trace ---
   at BenchmarkDotNet.Toolchains.Roslyn.Builder..ctor()
   at BenchmarkDotNet.Toolchains.Roslyn.RoslynToolchain..ctor()
   at BenchmarkDotNet.Toolchains.Roslyn.RoslynToolchain..cctor()
   --- End of inner exception stack trace ---
   at BenchmarkDotNet.Toolchains.ToolchainExtensions.GetToolchain(Runtime runtime)
...

binlog.zip

I attach a solution that contains both a repro app (ConsoleApp1) and the BenchmarkDotNet package source, to allow easy inspection of a debug build:
BenchmarkDotNet.zip

Previous discussion with BenchmarkDotNet maintainers at: https://github.com/dotnet/BenchmarkDotNet/issues/896. Their advice was to migrate from Visual Studio to Rider if I want to use their library in this situation but I would perfer to continue using Visual Studio if possible.

area-Infrastructure-libraries bug packaging

Source

sandersaares

Most helpful comment

Hang on a minute. That is a workaround, not a resolution to the defect in question.

I would consider this resolved if the scenario in the original post works without errors. You can't expect Visual Studio users to go digging in files that VS generates them and changing settings based on some obscure GitHub issue. That is not any sensible level of user experience. "Make framework-provided assemblies actually work" is something that I expect out of the box with default settings on all fronts.

sandersaares on 17 Oct 2018

👍7

All 13 comments

@joperezr does it ring a bell?
cc @adamsitnik

karelz on 11 Oct 2018

Their advice was to migrate from Visual Studio to Rider if I want to use their library in this situation but I would perfer to continue using Visual Studio if possible.

My advice was "remove the assembly binding redirects from the project"

I repeated this two times:
https://github.com/dotnet/BenchmarkDotNet/issues/896#issuecomment-427067121
https://github.com/dotnet/BenchmarkDotNet/issues/896#issuecomment-427371989

I have reported this bug a long time ago but it got ignored:
https://github.com/dotnet/corefx/issues/30642

adamsitnik on 11 Oct 2018

❤2

If it is duplicate, let's resolve one of them as dupe of the other.
@adamsitnik please work with @joperezr to find out what to do as next step. I wonder if the original issue was misrouted into wrong area path ...

karelz on 11 Oct 2018

Their advice was to migrate from Visual Studio to Rider if I want to use their library in this situation but I would perfer to continue using Visual Studio if possible.

I just wanted to highlight that it's not a problem with the .NET Framework, it's a problem with Visual Studio. Rider is an example of IDE which doesn't have this problem, so it's definitely an IDE issue.
@sandersaares you can use any IDE that you like. You can easily use BenchmarkDotNet with Visual Studio. The only known issue relates to the first-time library installation in the classic .NET project with specific NuGet settings (DependencyBehavior=Highest). The issue can be resolved in a few seconds because the workarounds are known.

AndreyAkinshin on 11 Oct 2018

I'm tracking related issues and information in a list. They are related to System.Net.Http, System.Runtime, System.IO, System.ValueTuple, System.Buffers and others.

All of these have the same very few underlying issues.

.NET 4.7.2 helps with some but not all of these. You can look at my comments on some of these issues for some ideas on how to work around those problems. I also have a central list of ideas to try.

GSPP on 14 Oct 2018

The problem here I believe is with the VS tooling when you add the nuget package reference. It shouldn't be adding that extra binding redirect. If you instead migrate your project to use PackageReference then installing a new package won't generate binding redirects, and only at build time will we figure out if you need extra binding redirects or not, which in this case you shouldn't need any for System.Runtime as it already comes inbox for 4.7.1.

@sandersaares can you try the exact same repro but instead of adding Benchmarkdotnet package via VS, simple add this to your project:

<ItemGroup>
  <PackageReference Include="BenchmarkDotNet" Version="0.11.1" />
</ItemGroup>

joperezr on 15 Oct 2018

👍1

@joperezr I confirm that using the steps you describe results in a successful execution of the app.

sandersaares on 16 Oct 2018

👍1

Closing as resolved. Thanks for confirmation @sandersaares!

karelz on 16 Oct 2018

Hang on a minute. That is a workaround, not a resolution to the defect in question.

sandersaares on 17 Oct 2018

👍7

I agree @sandersaares, that said, I don’t believe this is the right repo to log an issue with the vs nuget tooling, as the fix for this would most certainly not go in here. The issues on this repo are regarding bugs/problems with the framework itself. I would probably move this issue to either dotnet/sdk or nuget which are probably still not the right places but they might know how to re-route it better.

joperezr on 17 Oct 2018

Yeah, I did spend a few minutes considering where to file this. It is not obvious to me as a user what exactly is the cause of the issue, all I see is that my .NET app development is blocked.

Here is an attempt at a differently targeted repost: https://developercommunity.visualstudio.com/content/problem/360253/net-471-app-experiences-unexpected-could-not-load.html

Hrm, looks like that site doesn't do code blocks...

sandersaares on 17 Oct 2018

Yeah, I totally agree that as a user when you don’t know what is going on this is a good place to post it so that we can have an initial diagnosis. Now that we know the cause of this is the nuget package manager adding wrong redirects its a good time to move it where the fix would go :smile:

I think that choosing vs feedback was the right choice :)

joperezr on 17 Oct 2018

Yeah, I did spend a few minutes considering where to file this. It is not obvious to me as a user what exactly is the cause of the issue, all I see is that my .NET app development is blocked.

Microsoft has now been made aware of multiple severe bugs of this kind. Please reroute these issues internally to the right places. It is not for customers to run after Microsoft to find a place that would accept these bug reports.

GSPP on 19 Oct 2018

👍2

Was this page helpful?

0 / 5 - 0 ratings