Couldn't load assembly because of mismatching build number

.net .net-standard c# entity-framework-core

Question

Right now im restructuring my projects so I'll be able to target multiple frameworks.
Currently my solution is structured like this

MyProject (Solution)
    MyProject.Server (Project targeting net462)
    MyProject.Models (Project targeting netstandard2.0)
    MyProject.DataAccess (Project targeting netstandard2.0)

Models and DataAcces both reference Pomelo.EntityFrameworkCore.MySql, Version=2.1.1.0 via NuGet.
Models holds my database models and the database context while DataAccess contains a UnitOfWork pattern.
This worked fine when all projects targeted netfx and used EntityFramework 6 for database connections.
The projects just build fine and I dont have any problems to start them (I should probably mention here, that my project is a type of resource for a multiplayer modification. The resource files get loaded like this https://github.com/GTANetworkDev/platform/blob/master/Server/Resources.cs#L198 ourResource.Info.Info.Shadowcopy is in this case false).
But once my resource wants to open a connection to the database I get a kinda huge exception telling me that System.ComponentModel.Annotations, Version=4.2.0.0 is unable to load because of a version mismatch (https://hastebin.com/wodojakure.log).
The file System.ComponentModel.Annotations.dll exists but with following attributes

AssemblyVersion=4.2.1.0
AssemblyFileVersion=4.6.26515.06

I've already tried using a app.config to rebind the assembly which failed, for a reason that I don't really know.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <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>
    </assemblyBinding>
  </runtime>
</configuration>

The app.config existed in the same folder where the other resource dlls are placed in and in the same folder where the server executable lays in.

1
0
7/26/2018 12:33:58 PM

Popular Answer

The solution is, that the executable (which then invokes my dll) needs a config file where you specify the binding redirects and not the invoked dll itself.

Now it works like a charm. Thanks for the people trying to solve the problem.

0
7/27/2018 11:57:49 AM


Related Questions





Related

Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow