Newtonsoft.Json dependency trouble

[pavel-khritonenko]

I have an issue when I want to stick Newtonsoft.Json to ~6.0 version

An unhandled exception of type 'System.IO.FileLoadException' occurred in FsPickler.dll

Additional information: Could not load file or assembly 'Newtonsoft.Json, Version=7.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)

https://github.com/pavelhritonenko/fspickler-newtonsoft - repository for reproduce issue

[eiriktsarpalis]

You need to specify a binding redirect for Newtonsoft.Json if you are using a version different than 7.0.

[pavel-khritonenko]

@eiriktsarpalis I have one default generated by Packet, but it strange for me that FsPickler compiled with version higher than minimal supported. What do you think, should I address this issue to Paket developers?

[eiriktsarpalis]

Yes I've seen this. Not sure if bug or by design.

On Fri, 31 Jul 2015 at 10:57 pavelhritonenko notifications@github.com
wrote:

@eiriktsarpalis https://github.com/eiriktsarpalis I have one
https://github.com/pavelhritonenko/fspickler-newtonsoft/blob/master/fspickler-newtonsoft/App.config#L11-L14
default generated by Packet, but it strange for me that FsPickler compiled
with version higher than minimal supported. What do you think, should I
address this issue to Paket developers?

—
Reply to this email directly or view it on GitHub
#56 (comment).

[mvkara]

Bit late to the party - just trying this framework now and with a dependency on another version of Newtonsoft in my code out this is causing me headaches. Is it possible to just remove the dependency of Newtonsoft.Json from the codebase? Maybe a stupid question. Newtonsoft is MIT licensed; doesn't that mean worse comes to worse you can just use the JsonWriter and BsonWriter's as code inside the library? I know RavenDB has done this for their JSON serialisation. Not sure if you are relying on any functionality to help with F# types for example; it would simplify things a lot.

[eiriktsarpalis]

@mvkra I once tried doing that, but the JsonWriter/Reader types depend on a significant segment of the Json.Net library. I would like to write my own JsonWriter/Reader implementations using F# at some point, I'm sure it would benefit deserialization performance. Haven't found the time to do this yet.

Does adding a binding redirect not fix your problem?

[mvkara]

It does if I play with it right but I would rather just use Json.net then
most of the time (would rather just use one library rather than two). Keeps
it simple. Of course that means I don't use this library hence the
suggestion.
On 13 Nov 2015 9:40 AM, "Eirik Tsarpalis" notifications@github.com wrote:

@mvkra https://github.com/mvkra I once tried doing that, but the
JsonWriter/Reader types depend on a significant segment of the Json.Net
library. I would like to write my own JsonWriter/Reader implementations
using F# at some point, I'm sure it would benefit deserialization
performance. Haven't found the time to do this yet.

Does adding a binding redirect not fix your problem?

—
Reply to this email directly or view it on GitHub
#56 (comment).

[dsyme]

Closing this old discussion/question