25

I am getting this error whenever I try and run a webjob project with application insight and entity framework.

System.IO.FileLoadException: 'Could not load file or assembly 'System.Runtime.InteropServices.RuntimeInformation, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)'

I have installed the following nuget packages

Microsoft.Azure.WebJobs.Logging.ApplicationInsights version 2.1.0-beta4

Microsoft.Extensions.Logging version 2.0.0

Microsoft.Extensions.Logging.Console version 2.0.0.

This all works with a new Visual studio 2017 webjob project, its when I try and include an existing code base, primarily using entity framework that I get this error. When I look at the reference in the one that works I don't have the System.Runtime.InteropServices.RuntimeInformation, yet it has been added to the project with entity framework. It seems to be part of .net standard, but how come I don't need .net standard for my new console app!

enter image description here

I'm not sure why its looking for Version 0.0.0.0 either as the one I have is 4.0.2.0

I have also tried adding this to the project file but this didn't work.

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

Any help would be greatly appreciated

Many thanks

Andrew
  • 1,352
  • 1
  • 18
  • 32

3 Answers3

45

Confirming the comment made above by dwilliss also worked for me. The solution was to get rid of:

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

(In my case from the app.config, for a Windows Service.) My project has an indirect dependency to System.Runtime.InteropServices.RuntimeInformation only. It is a dependency of a NuGet package I imported.

Adam
  • 649
  • 1
  • 5
  • 7
  • 4
    Related [anouncement on Github](https://github.com/dotnet/standard/issues/567) which explains why (in what cases) removing binding redirect might help. Full list of suggestions to try - https://github.com/dotnet/standard/issues/481#issuecomment-429653699 – Michael Jul 24 '19 at 14:52
  • Many many thanks. Commented the code out of web.config and it worked perfectly. – HumbleBeginnings Apr 03 '20 at 01:09
  • Mostly adding bindingRedirects solves dll hell issues. This time removing it solved it. I would had spend hours to figure it out without this answer. – rfcdejong Oct 20 '20 at 09:00
23

Could you be missing the loaded assembly from your configuration file? Ensure you have something similar to the following within your web.config. NuGet would normally do this but maybe it hasn't and it doesn't know what to load in

<dependentAssembly>
  <assemblyIdentity name="System.Runtime.InteropServices.RuntimeInformation" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-4.0.2.0" newVersion="4.0.2.0" />
</dependentAssembly>
Jono_2007
  • 904
  • 3
  • 10
  • 22
  • 34
    This may seem backwards, but I recently had this problem as well and the dependentAssambly for it (as well as several other packages) was already added to the web.config by a NuGet package that I had installed. In my case, _getting rid of_ the newly added dependentAssembly entries fixed the problem. Just something else to try. – dwilliss Sep 11 '18 at 15:44
  • @dwilliss Your solution worked for me. Thank you for pointing that out. – CPerson Oct 29 '19 at 21:15
  • Why this works: If you look at the version of the assembly Visual Studio deploys, it's version 4.0.1 in my case. As far as Visual Studio can tell, your code only references (directly or indirectly) version 4.0.1 explicitly, so that's all that gets copied into the output directory. I guess if it wasn't copied at all, that would indicate it's included in the framework. If you rebuild binding redirects with (Add-BIndingRedirect) it doesn't add that redirect to 4.0.2, which confirms it's not needed, and actually harmful in this case. Alternatively, add a real reference to version 4.0.2. – Triynko Mar 09 '20 at 19:37
  • Worked for me - this is also a relevant solution for app.config. – wildbagel Feb 25 '21 at 15:58
3

If you have updated a project's .NET runtime version from a version before 4.7.1 to 4.7.1 or later then uninstall the Nuget package, delete / comment out the App.config part if it remains, and re-add the reference from the framework. It is in the framework from 4.7.1 onward, before that you had to add a Nuget package.

[edit]... as per Michael's comment above that I upvoted before living memory.

CAD bloke
  • 7,546
  • 6
  • 58
  • 104