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=126.96.36.199 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=188.8.131.52 is unable to load because of a version mismatch (https://hastebin.com/wodojakure.log).
System.ComponentModel.Annotations.dll exists but with following attributes
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-184.108.40.206" newVersion="220.127.116.11" /> </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.
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.