Consider Keeping Newtonsoft.JSON as an Optional Package Or Otherwise refactoring Nuget Packaging

[to11mtm]

One of the reasons many organizations have adopted RestSharp is because it is a lightweight library that doesn't have hard dependencies on things like Newtonsoft.JSON.

If you must have Newtonsoft as part of the 'standard' install, Please consider splitting the nuget packaging up such that people are not forced to take it as a dependency i.e. the Restsharp package consists of Restsharp.Core (no built-in-serializer, or SimpleJson) and Restsharp.Serializers.Newtonsoft.

[alexeyzimarev]

That might be an option, but please define many organisations and what is the source of your data. Also, quite a lot of Microsoft own packages have a dependency on Newtonsoft.Json, so I don't really see this as an issue.

My problem, as the maintainer, is that we have tons of issues with JSON serialisation and I don't want to start fixing SimpleJson.

[to11mtm]

'Many' was admittedly a point without a lot of solid data to back it up.

I can state that at both the current org I am at, as well as the previous, we used RestSharp either with the default SimpleJson, or with another Serializer. And a driving point towards RestSharp in both cases was that it did not force us to take a dependency on Newtonsoft. In one case it was primarily convenience (Minimizing Assembly Redirect concerns.) The other case was due to the version of MassTransit in use.

I can certainly empathize with JSON Serialization Issues. Ironically I ran into one with RestSharp+SimpleJson just after writing this issue.

[alexeyzimarev]

Actually, being the MassTransit organization member, I always considered it as one of the examples where the dependency on Newtonsoft.Json was never an issue. The MT repository has exactly ZERO issues about serialisation and we have like 40% of them, which is very frustrating.

I could consider having a RestSharp.Core library that has no default serialisation and RestSharp that would depend on both the Core and Newtonsoft.Json.

[alexeyzimarev]

Although, the name Core will be confusing, since people will definitely think that it is the version, which supports .NET Core. I believe, even the package name is used by someone.

[to11mtm]

Actually, being the MassTransit organization member, I always considered it as one of the examples where the dependency on Newtonsoft.Json was never an issue. The MT repository has exactly ZERO issues about serialisation and we have like 40% of them, which is very frustrating.

So, I'll be the first to admit this is a chain of issues that lead to the problem in question;

The version of MassTransit in use is/was 2.9.0. At some point after Newtonsoft Version 6.0.6, JsonDictionaryContract.PropertyNameResolver was renamed to JsonDictionaryContract.DictionaryKeyResolver.

This means if you upgrade Newtonsoft.JSON past a certain version, You'll have runtime exceptions in the MassTransit v2 JsonContractResolver. You can get around this with some re-implementation of the MT JsonSerializer, But it is still a bit of a hassle. The other option is upgrading MT to Version 3, which is more work.

But aside from that older example, there have been other issues in projects such as NEST, RawRabbit, Hangfire, and even Windows XAML. While Newtonsoft is an amazingly useful and robust Json Parser, The end result of such wide adoption is that the end library consumers have to juggle versions of both Newtonsoft and the Newtonsoft consuming libraries.

[alexeyzimarev]

Well, I see your issue. But, if you decided to keep MT 2.9, when the latest is 5.3.1, why can't you also keep RestSharp 106?

[alexeyzimarev]

I know that .NET Core 3 will have its own JSON serializer. Maybe we just need to wait for it?

[alexeyzimarev]

Yeah, it seems like we will keep all serializers outside and RestSharp will still be with zero dependencies. Serializers would need to come in separate packages but everything will live in one repo.

[alexeyzimarev]

Here is the template message concerning JSON serialization.

We are closing tickets that concern issues with JSON serialization after the 106.10.0 release, which includes new packages to support serialization using NewtonsoftJson, Utf8Json and System.Text.Json.

Most certainly, your issue will be resolved by using one of those serializers. Don't forget to check the serialization options, which can affect the ability to deserialize your request on the server-side or deserialize the response.

Please refer to the updated documentation about serialization.