EF Core 2.1.4 FileLoadException System.ComponentModel.Annotations 4.2.0.0

Question

After upgrading our data access layer from EF6 to EF Core 2.1(.4) we are having trouble with a FileLoadException with System.ComponentModel.Annotations, Version=4.2.0.0, which is odd since EF Core 2.1.4 uses 4.5.0.0, and nothing else (we can find) in our solution uses 4.2.0.0.

Say for example we have the following project structure in our solution:

DataAccess: (all projects using Microsoft.EntityFrameworkCore.SqlServer Version 2.1.4)
- Models (Only the models created with Scaffold-DbContext)
- Core (Abstract providers, persisters, etc.)
- Common (DTOs, concrete providers, persisters, etc.)

Main Solution: (no projects have EF Core package installed)
- Some project (A) with project references to Models, Core, Common

Even if project A is, for example, a simple console app that just loads something from the database and displays it to the console, when something is evaluated at the abstract provider level in DataAccess.Core, we get the following exception:

System.IO.FileLoadException occurred HResult=0x80131040 Message=Could not load file or assembly 'System.ComponentModel.Annotations, Version=4.2.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)

What is strange is that we can't find System.ComponentModel.Annotations, Version=4.2.0.0 anywhere, the version is even skipped in Nuget.
Trying the accepted answer in this question: Could not load file or assembly 'System.ComponentModel.Annotations, Version=4.1.0.0 , by adding the following to my .csproj files seems to fix the issue for some projects, but not all:

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

In the generated DataAccess.Models.dll.config files after building the only reference to System.ComponentModel.Annotations is the following:

<dependentAssembly>
  <assemblyIdentity name="System.ComponentModel.Annotations" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-4.2.1.0" newVersion="4.2.1.0" />
</dependentAssembly>

Which isn't 4.2.0.0, but we're not sure where that new version number is being decided on. It's probably something minor we've missed or incorrectly configured, but some assistance in finding the issue or pointers on where to look would be appreciated. A solution where we don't have to add AutoGenerateBindingRedirects to every .csproj file would be ideal

This is an existing problem that seems difficult for Microsoft to fix. Possible because it involves cooperation between multiple development groups. It only occurs in some more complex solutions. The solution is quiet simple. Change the bindingRedirect mentioned above to the following: and the chances are quiet reasonable that your problem goes away. This bindingredirect can be automaticlly applied in multiple projects. Tests which one(s) are causing your problem. — JRB, Oct 11 '18 at 09:41
@JRB That worked, thank you! Do you have any idea why it did not work with `newVersion="4.2.1.0"`? How can you automatically apply the bindingredirect in multiple projects? Is there something I can change/set in the base DataAccess projects that will enforce the binding redirects in all calling applications, as many different solutions depend on these projects? — JChristen, Oct 11 '18 at 10:38
@JRB Also, if you want to change your comment into an answer I will gladly accept it — JChristen, Oct 11 '18 at 10:39
JChristen : in its current form the error in auto generating binding redirects of "System.ComponentModel.Annotations" was introduced in EF Core 2.1, but earlier there were similar problems. In my situation I always need to manually change (in app.config) the autogenerated binding Redirects in solutions where I have both .Net Framework (WCF service using EF.Core) and .Net Framework projects (Windows service) within the same solution. In my comment above I should have said "In multiple projects within the same solution". I will rework my comment into an answer in the near future. — JRB, Oct 11 '18 at 11:55
@JRB you should totally make this the answer, as this just worked for me. Thank you VERY much! — Gary Ewan Park, Dec 20 '18 at 14:01
@JChristen - Is this app a .net framework app consuming .net standard classes? — Blane Bunderson, Mar 25 '19 at 18:20

score 1 · Accepted Answer · answered Mar 13 '19 at 15:05

Content from @JRB's comment, formatted as an answer for readability:

This is an existing problem that seems difficult for Microsoft to fix, possibly because it involves cooperation between multiple development groups. It only occurs in some more complex solutions. The solution is quiet simple. Change the bindingRedirect from

<bindingRedirect oldVersion="0.0.0.0-4.2.1.0" newVersion="4.2.1.0" />

to

<bindingRedirect oldVersion="0.0.0.0-4.2.1.0" newVersion="4.0.0.0" />

and the chances are quiet reasonable that your problem goes away. This bindingredirect can be automaticlly applied in multiple projects. Tests which one(s) are causing your problem.

score 0 · Answer 2 · answered Feb 03 '20 at 05:43

I had the same issue. I have solved it by implementing the following helper function redirecting the assembly at the begin (which was suggested in this answer):

public static class FunctionsAssemblyResolver
{
    #region Public Methods

    public static void RedirectAssembly()
    {
        AppDomain.CurrentDomain.AssemblyResolve += ResolveAssemblyOnCurrentDomain;
    }

    #endregion Public Methods

    #region Private Methods

    private static Assembly ResolveAssemblyOnCurrentDomain(object sender, ResolveEventArgs args)
    {
        var requestedAssembly = new AssemblyName(args.Name);
        var assembly = default(Assembly);

        AppDomain.CurrentDomain.AssemblyResolve -= ResolveAssemblyOnCurrentDomain;

        try
        {
            assembly = Assembly.Load(requestedAssembly.Name);
        }
        catch
        { }

        AppDomain.CurrentDomain.AssemblyResolve += ResolveAssemblyOnCurrentDomain;

        return assembly;
    }

    #endregion Private Methods
}

EF Core 2.1.4 FileLoadException System.ComponentModel.Annotations 4.2.0.0

2 Answers2