IMPORTANT: Please test version 103.0.0-nojsondotnet

[John Sheehan]

I got fed up with dealing with JSON.NET's ridiculous strong-naming and the issues that caused so I updated the JsonDeserializer to work without it last night. You can find it on NuGet as a pre-release package https://nuget.org/packages/RestSharp/103.0.0-nojsondotnet 

Please install it and test your apps with it and report back any issues to the group.

Note that the JsonSerializer was also updated and is no longer compatible with Json.NET configuration. If you need that in your app, you'll need to implement your own ISerializer and register it.

[Daniel Corbett]

I posted an issue on it already, before I found the group

I DID implement the code which creates a JsonSerializer that uses the JSON.Net one, but it appears to be only used for de-serializing, not serializing.

I agree with the concept of decoupling it, but it heavily breaks a project that S I use -- Neo4jClient, which depends on the Serialization Attributes used by JSON.Net.  The Preview Nuget doesn't provide a way to specify the Serializer - the serializer is hardcoded in the constructor.   Can an additional constructor be added where the Serializer can be passed as an argument?

Thanks!

   - Daniel

[Daniel C]

Never mind... I was able to make this work.   I am looking forward to eliminating the issues  with multiple versions of JSON.Net between different open source project!  :-)

[LTG]

I must be the only one in the dark - could you please elaborate on why
it is bad to use Json.Net?

Concerns:
- Having less de/serializers is better. Less moving parts.
- I see that you can swap it out - don't want to swap need less
config not more
- The new one is not compatible, wth?
- Even Microsoft is using Json.Net to drive MVC 4.5 WebApi. Yes MS
chose it over their own multiple implementations.

With respect to your contributions I wish it were not so.

Regards -

On Apr 4, 6:20 pm, John Sheehan <johnshee...@gmail.com> wrote:
> I got fed up with dealing with JSON.NET's ridiculous strong-naming and the
> issues that caused so I updated the JsonDeserializer to work without it
> last night. You can find it on NuGet as a pre-release
> packagehttps://nuget.org/packages/RestSharp/103.0.0-nojsondotnet
>

> *Please install it and test your apps with it and report back any issues to
> the group.*
> *
> *

[John Sheehan]

Deserialization (by far, the most common case that used JSON.NET) is
100% compatible as far as I can tell. The tests passed and there
haven't been any reports related to deserialization that is not
compatible. Serialization, far rarer, is mostly compatible. Only if
you were using JSON.NET-specific attributes would you need to
configure it for compatibility.

JSON.NET strong names assemblies and NuGet does not handle this well.
At. All. When JSON.NET updates their assembly version and people
update it via NuGet, it breaks RestSharp. There are workarounds and
hacks, but none are fool proof and most just trade one set of problems
for another. And the result when things go wrong is I get tons of
support email I can't answer. Any update to JSON.NET could break
RestSharp and any lib that depends on RestSharp at an indeterminate
time. This costs companies real money and it costs me real time that I
don't have. I don't think that's acceptable.

RestSharp was also barely using JSON.NET and carrying around 460KB+
for the privilege. That's ~2.5x the size of RestSharp itself.

JSON.NET was mostly completely abstracted away, save for rarely-used
serialization configuration that was never publicly supported. The
one-time inconvenience for that small set of users was acceptable
collateral damage for the health of the project. For the first time in
months I wrote code for RestSharp because I had time that was no
longer being spent on ridiculous dependency issues. JSON.NET had to go
or RestSharp had to.

I hope this is the last time I ever have to talk about this. Let's all
move forward.

[LTG]

Fair enough John -

RestSharp is really a nice project and is appreciated -

[Victor Ponce]

I upgraded to the latest version and now I get an InvalidCastException. I didn't get any errors before. This is the stack trace:

   at RestSharp.RestClient.<>c__DisplayClass2a`1.<ExecuteAsync>b__29(IRestResponse response, RestRequestAsyncHandle asyncHandle)
   at RestSharp.RestClient.ProcessResponse(HttpResponse httpResponse, RestRequestAsyncHandle asyncHandle, Action`2 callback)
   at RestSharp.RestClient.<>c__DisplayClass23.<ExecuteAsync>b__20(HttpResponse r)
   at RestSharp.RestClient.<>c__DisplayClass25.<>c__DisplayClass27.<ExecuteAsync>b__22(Object s)
   at System.Reflection.RuntimeMethodInfo.InternalInvoke(RuntimeMethodInfo rtmi, Object obj, BindingFlags invokeAttr, Binder binder, Object parameters, CultureInfo culture, Boolean isBinderDefault, Assembly caller, Boolean verifyAccess, StackCrawlMark& stackMark).................

I saw another post in the group about this same exception after updating it

On Wednesday, April 4, 2012 7:20:49 PM UTC-4, John Sheehan wrote:

[Radu Simionescu]

You are wrong. The problem is not with JSON.NET. In my working environment, we reference various libs which require various versions of JSON.NET (SignalR among them) and our own code which uses the up to date version of JSON.NET which gets updated once in a while, and NUGET handles all conflicts with no problems. I see the issue must be with RestSharp...

Sorry

[Brett Ryan]

I don't mean to offend Radu, but that's a very narrow minded argument you have put forward.

You may care to review the various problems that JSON.NET was causing and reevaluate your post. Maybe contribute a "fix" to a fork of a prior version using JSON.NET.

The project has moved on though, there's no use in mulling on the subject.

--
You received this message because you are subscribed to the Google Groups "RestSharp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to restsharp+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[shen benny]

what does this mean exactly, do I need to do more work in order to use RestSharp than previously?

在 2012年4月5日星期四 UTC+8上午7:20:49，John Sheehan写道：

[Jura Bondarchook]

This is problem with JSON.NET  

I discribed this problem in my post http://stackoverflow.com/questions/31608983/newtonsoft-json-net-version-incompatibility

Becicaly, because JSON.NET has wrong versioning policy, it  is very bed idea to put it to GAC

I log a diffect on JSON.NET but it was closed. That guy does not understand what he doing wrong.  

Everything that uses JSON.NET potencialy can broke other programs that use JSON.NET but creator of JSON.NET simply do not understand how .NET works 

[Jura Bondarchook]

I discribed this problem in my post http://stackoverflow.com/questions/31608983/newtonsoft-json-net-version-incompatibility

I log a diffect on JSON.NET but it was closed. That guy does not understand what he doing wrong.  (https://github.com/JamesNK/Newtonsoft.Json/issues/615)

That Newtonsoft.Json guy simply do not understand how .NET versioning works, and many products failing with this types of errors

[Goran Grubić]

I'm so glad it's not my personal problem with JSON.NET but also others noticed issues using this package.
:) I'm about to apply RestSharp in my solution. While reading about it I sow "JSON.NET" and my brain was screaming: no no no not again !! :)

[Alexey Zimarev]

JSON.NET is included to ASP.NET Core by default. RavenDb, MassTransit and many other projects use this serialiser without any issues.

I am wondering what this "screaming" would be coming from?