Replace Newtonsoft.Json with System.Runtime.Serialization.Json

[zvrba]

No library has caused me as much deployment grievances as Newtonsoft.JSON. It's a known problem, package A wants 6.x, package B wants 10.x and I want to use both A and B in my project. Usually, it's fine to include assembly redirects (unless you want to develop Powershell cmdlets, but that's another story), but this raises the question: IF 10.x is upwards-compatible with 6.x, why has the MAJOR version changed?! (Fusion fails on major version mismatch.)

The issue has been raised with the author of Newtonsoft.JSON [1, 2, 3], to no avail. Microsfot, PLEASE, revive and/or use https://docs.microsoft.com/en-us/dotnet/api/system.runtime.serialization.json?view=netframework-4.7.1 instead of a 3rd-party lib.

[1] JamesNK/Newtonsoft.Json#615
[2] JamesNK/Newtonsoft.Json#1001
[3] https://stackoverflow.com/questions/31608983/newtonsoft-json-net-version-incompatibility-dll-hell

[markusschaber]

Alternatively, they could maintain their own build (and NuGet Package) as a parallel fork, with sane naming and versioning policy.
We had similar problems with another library some time ago, and our solution was to build ourself, using our own snk file, so we get our own "strong name". That way, we can make sure we have unique version numbers, and the framework cannot load wrong assemblies because it prefers GAC to local installation directory.
It's a shame that applications cannot suppres loading from GAC (or at least repriorize GAC to be searched after local directories...)

[jzabroski]

@markusschaber Maybe we should take a step back and ask why Newtonsoft is on release 10+: are these features or bugs.

NewtonSoft.Json (aka Json.NET) claims to be fast, but it's also quite slow:

Json.NET is a popular high-performance JSON framework for .NET
Source: https://github.com/JamesNK/Newtonsoft.Json

[markusschaber]

@jzabroski The other question is whether the other serializers have all the features which come with Json.Net - in our current project, the customization to enable auto-mapping of property names between camelCase and PascalCase comes in handy, as we need to talk with code with other naming conventions.

But on the other hand, we just settled with NewtonSoft because it comes with .NET Core, and was already successfully used in other projects in our house...

[asears]

This (or similar) issue just bit us with Azure Automation. AA uses JSON.NET v6 and Powershell AzureRM.profile library uses v6 and v10. Have seen a number of these issues related to Powershell / AzureRM and Newtonsoft JSON.

Running Get-AzureRmDataFactoryV2Pipeline on Hybrid Worker:

Logging in to Azure...
Get-AzureRmDataFactoryV2Pipeline : Method not found: 'Newtonsoft.Json.Serialization.IAttributeProvider 
Newtonsoft.Json.Serialization.JsonProperty.get_AttributeProvider()'.
At line:18 char:1
+ Get-AzureRmDataFactoryV2Pipeline -ResourceGroupName

This method was introduced in JSON.NET v7.
https://github.com/JamesNK/Newtonsoft.Json/commits/master/Src/Newtonsoft.Json/Serialization/IAttributeProvider.cs

Modules installed

ModuleType Version    Name                                ExportedCommands                                                                                                                                  
---------- -------    ----                                ----------------                                                                                                                                  
Script     0.5.8      AzureRM.DataFactoryV2               {Set-AzureRmDataFactoryV2, Update-AzureRmDataFactoryV2, Get-AzureRmDataFactoryV2, Remove-AzureRmDataFactoryV2...}                                 
Script     5.4.0      AzureRM.profile                     {Disable-AzureRmDataCollection, Disable-AzureRmContextAutosave, Enable-AzureRmDataCollection, Enable-AzureRmContextAutosave...} 

Resolution

Using Process Monitor, it seems as though the first Json.NET dll picked up is from the command line used to run commands on the hybrid agent and not the Powershell one.

Copy the associated Newtonsoft.Json.dll and Newtonsoft.Json.10.dll from C:\Program Files\WindowsPowerShell\Modules\AzureRM.profile\5.4.0 to
C:\Program Files\Microsoft Monitoring Agent\Agent\AzureAutomation\7.2.14544.0\HybridAgent\ fixes the issue.

Similar issues

Azure/azure-powershell#6250
https://stackoverflow.com/questions/31608983/newtonsoft-json-net-version-incompatibility-dll-hell
Azure/azure-powershell#5826
Azure/azure-powershell#6313
Azure/azure-powershell#5977

Please get rid of 3rd-party dependencies where possible or assist James with solution. Json.NET is great when it works.

[Petermarcu]

The Azure SDK is planning to remove references to JSON.NET in upcoming releases to avoid pinning dependencies like this. It will take time to get through all the different places where this dependency exists but over time, the pain should go away. We want people to be able to use whatever JSON.NET version they want without the Azure SDK causing problems.

You can get a glimpse of the first wave of libraries doing this here: https://azure.microsoft.com/en-in/blog/previewing-azure-sdks-following-new-azure-sdk-api-standards/