Newtonsoft.Json v10 problem

[hikalkan]

Hi,

I'm getting this exception:

Could not load file or assembly 'Newtonsoft.Json, Version=9.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception
from HRESULT: 0x80131040)

We are using Newtonsoft.Json 10.0.0.2, but probably migrator tool looks for 9.0.0.0. Do you know a solution or workaround?

Thanks.

[reberinformatik]

Same here, what about:

https://github.com/mrahhal/Migrator.EF6/blob/1a3fea03c37abc6da28fb4e33040f187cdc0169f/build.cake#L1

#addin "nuget:https://www.nuget.org/api/v2?package=Newtonsoft.Json&version=9.0.1"

[hikalkan]

How can we add assembly binding for that, as it can not work when we add it to our project?

[mrahhal]

Hi,

@hikalkan where and when are you facing this problem? Can't reproduce it with 1.1.3 on a project that has a reference to Json.Net 10.0.2. It's true though that some of migrator's dependencies depend on Newtonsoft.Json 9.0.1. So it's a transitive one. An assembly binding should fix this, but I have to reproduce it first.

@reberinformatik this is just the build script, it does not interfere with the package itself.

[mrahhal]

Ah, this might be related to #37.

As a summary, the problem is with how transitive dependencies are being resolved. But this shouldn't happen as long as you're using a pure class library project for the migrations (without a dependency on asp.net core). No idea how to fix this other than applying binding redirects, until the dotnet team fixes it.

[hikalkan]

Thank you for your time. Where should I write assemblyBinding? Adding it to library's config file does not help since the executing application looks at it's own config file. Where is the migrator's exe?

[mrahhal]

@nphmuller do you have anything to say on the subject? Since you've given this some effort.

@hikalkan @nphmuller's comment here might give you some ideas.

I still can't reproduce this. I looked at aspnetboilerplate/aspnetboilerplate#2040 and it might be that your Abp.Zero package (or one of its siblings) has a transitive dependency on something that fishes this out (which is why I can't repro it).

[nphmuller]

@mrahhal @hikalkan I haven't looked into this issue specifically, but one of my projects also has a reference to Newtonsoft.Json 10.x and my workaround still works there. The workaround is a few comments below the one @mrahhal linked. Here

[mrahhal]

I believe that simply referencing Json.Net doesn't cause a problem (even without the workaround), I have it referenced and it works properly. Something up the stack (related to asp.net core maybe) must be causing this.

I opened an issue a long time ago about this here: dotnet/cli#6028

[nphmuller]

@mrahhal You're right, I just removed the Newtonsoft,Json assemblybinding from my workaround, and it still works properly. So I can't reproduce it.

I even tried adding all package references from https://github.com/aspnetboilerplate/aspnetboilerplate/issues/2040#issue-222089925 duplicating the app.exe.config to dotnet-ef.exe.config and removing the assemblybinding for Newtonsoft.Json. Still works.

@hikalkan Do you have some more information about how to reproduce the issue? Maybe even the full csproj file might help.

[reberinformatik]

@nphmuller I tried it too in my aspnetzero-project with different approaches. What really helped was this: Adding the copy-instruction into the MyProject.EntityFramework.csproj:

  <!-- Workaround for Migrator.EF6 assembly version binding problem. See: https://github.com/mrahhal/Migrator.EF6/issues/37/ -->
  <Target Name="ToolingAssemblyBinding" AfterTargets="Build">
    <Copy SourceFiles="$(OutputPath)$(AssemblyName).exe.config" DestinationFiles="$(OutputPath)dotnet-ef.exe.config" />
  </Target>

It was not necessary to add a binding-redirect into the MyProject.EntityFramework/App.config because AutoGenerateBindingRedirects was set to true. This leads to an automatically generated binding-redirect in MyProject.EntityFramework.exe.config (which will be copied to dotnet-ef.exe.config with the workaround above). So the dotnet-ef.exe.config is definitely required in my case.

Note also that the file will not be deleted if you remove the workaround (you have to clean the output folder first).

Thanks a lot to all of you for the provided workaround!

[mrahhal]

@reberinformatik nice, thanks for confirming. Waiting for @hikalkan to confirm that this fixes it.

[hikalkan]

This workaround worked for me. Thank you very much @reberinformatik and @mrahhal

[nphmuller]

@reberinformatik Yeah, that was the workaround I initially linked to. Still couldn't get the issue reproduced, though.

Glad you got it to work!

[oakuraape]

This work around worked for me too - thanks.