Azure-functions-host: Remove JSON .NET unification

[fabiocav]

Opening this issue to track work that needs to happen across a few different components, enabling us to remove the unification behavior that currently exists in the host for this dependency.

At a high level, the following needs to happen:

• Update HTTP (other bindings for consistency, but HTTP is required) to remove the host dependent binding on JSON.NET and use the appropriate abstractions
• Update host pinning configuration
• Add compatibility flag to support migration/ensure existing behavior is maintained

/cc @mattchenderson

[NickDarvey]

Out of interest, why the need for compatibility?

(I'm assuming the major version increment from v2 to v3 implies other breaking changes, or... maybe not?)

[metro-mark]

@NickDarvey I can point out a couple of issues with 1.x that I have gone through. Azure storage API required JSON.NET higher than 9.01. Cosmos DB API wouldn't work with 1.x, especially using .net API when trying to retrieve any records using LINQ queries. It works fine on other solutions such webapp and console apps. Finally I have a third party e-signature application that requires JSON.NET of 11.02 or higher and it did not work when using 1.30 beta 1 or 2 with JSON.NET 11.0.2 installed. It worked on other platform such as webapps and console apps.
I have custom apps that use third party libraries whose provider refuses to provide .net core compatible libraries, which forces me to stay in .net framework area. I am not against .net core. It's just that as Scott Hanselman has brought out .net conference and even at the Ignite conference today, .net framework is here to stay and .net core provides better performance and better compatibility with modern applications. In the same token, I would like Azure function team to continue improving 1.x function, not sunsetting it.

[paulbatum]

@NickDarvey We are making an effort to minimize breaking changes in this particular major release (discussed somewhat here).

[IanKemp]

I have custom apps that use third party libraries whose provider refuses to provide .net core compatible libraries, which forces me to stay in .net framework area.

This problem is between you and that provider, it's not Microsoft's and it's not ours. You're welcome to fork this repo and update it to support Framework, you could even submit those changes back so others with the same issue can benefit.

I am not against .net core. It's just that as Scott Hanselman has brought out .net conference and even at the Ignite conference today, .net framework is here to stay and .net core provides better performance and better compatibility with modern applications. In the same token, I would like Azure function team to continue improving 1.x function, not sunsetting it.

Microsoft has made it very clear by their actions that Framework is dead. They are never going to state this publicly, but that is the harsh truth and expecting them to continue supporting everything for forever is not going to happen. They spent two decades with that headache with Windows, they are a different company now that is not willing to let itself be a slave to backwards compatibility because that means less resources to spend on new features and improvements that allows them to remain competitive with other languages and frameworks.

Does this suck for certain people, like yourself? Yes. Do I believe it's the correct strategy? Not entirely - the amount of money that Azure continues to make for Microsoft, plus the effective outsourcing of testing to end-users via Windows Insider and GitHub (a practice I strongly disagree with), should mean that there is a lot more cash for them to hire more developers. But unfortunately Microsoft is a public company, and shareholders expect dividends to increase every year, and supporting older tech as well as creating new tech increases dividends less than just creating new tech.

So if you want this to change, you need to fix capitalism, and good luck with that.

[PureKrome]

whoa ! that got deep ... real quick 😃

[metro-mark]

@fabiocav and @NickDarvey and @paulbatum Do you concur with @IanKemp 's comment?

[paulbatum]

@metro-mark To be honest you kind of sidetracked this issue. The removal of JSON unification behavior from the runtime and the state of .NET framework support in functions are two separate conversations. For the latter, I would suggest this github issue:
https://github.com/Azure/Azure-Functions/issues/790

Please have this conversation there.

[briandunnington]

@fabiocav @paulbatum This might be the wrong place for this but I cannot get find a definitive answer anywhere else. Do HTTP triggers in v3 use JSON.NET for serializing responses still, even though the underlying .NET Core 3.1 runtime uses the new System.Text.Json classes? Experimentation shows that HTTP response objects are serialized with JSON.NET - is there a setting/config to change to System.Text.Json? Is that what this item represents? Is there any documentation that states which json serializer is used in Azure Functions?

5469 seems to imply that Azure Functions still (only?) uses JSON.NET

[hansmbakker]

I'd also like to use System.Text.Json in my code

[IanKemp]

I'd also like to use System.Text.Json in my code

Nothing is stopping you.

This topic is about removing Newtonsoft.Json since System.Text.Json effectively obsoletes it.

[hansmbakker]

Since Azure Functions uses NewtonSoft.Json under the hood, I believe cannot configure the serialization settings with classes from System.Text.Json.

[AartBluestoke]

@hansmbakker the main issue is that the only version of NewtonSoft.Json you can use is the embedded one (v9 for functions v1 and v11 for functions v2,v3).
Other than that you can load and (de)serialize your bytes any way you want.

[hansmbakker]

So you're saying that you can use System.Text.Json when

• returning an OkObjectResult,
• when using the built-in deserialization of trigger input
  ?

I don't see how to do that?

[pheuter]

This issue appears related: https://github.com/Azure/azure-functions-host/issues/5469

I am also currently running into the problem of needing to use a custom JsonConverter that's designed to work with System.Text.Json, but Azure Functions appears to enforce Newtonsoft with no way to override in Startup.Configure