Functions ≥1.0.24 not comptabile with up to date Newtonsoft.Json 12.x

[hf-kklein]

This issue is similar to #209, #237 and #259 .

Newtonsoft.Json 12.0.1 is stable since 2018-11-27. Please don't stick to

Microsoft.NET.Sdk.Functions 1.0.24 -> Newtonsoft.Json (= 11.0.2).

[espray]

Azure Functions Runtime 2.0.12265 supports Core 2.2, 2.2 packages like EntityFrameworkCore require >= 12.0.1

@fabiocav Can this package get updated with Newtonsoft.Json >= 12.0.1?

[ranouf]

How is it going to update the package dependancy to Newtonsoft.Json >= 12.0.1?

[chrisdreams13]

Almost 3 months and still the same error, are there plans to modifying?

[Carl012]

Any news on this? Any possible workaround?
I can't downgrade Newtonsoft.Json to anything below 12.0.1 as I rely on packages (both in-house and outside of our control) that requires >= 12.0.1

Since I couldn't find any workaround, my understanding is that I can't use Azure Functions and will need to rely on something else to achieve my goals.

Edit:
It seems I freaked out a bit fast. If I include specifically Newtonsoft 12.0.1 package in the Function project, it only reports warning (which makes sense).
Runtime seems to work fine, but I'm afraid I'm exposing myself to some possible nasty side-effects...

2nd Edit:
Nasty side-effects didn't take long to show themselves. This is clearly a showstopper as soon as you try to use some more advanced features around NamingStrategy and JsonSerializerSettings, which is understandable since Newtonsoft.Json 12 brought some changes there.

Is there a valid reason to fix the dependency version to 11? Is there any workaround?
I don't really see a scenario using the CosmosDb trigger where one would not want to control deserialization, except the simple examples where only the count and id of a document are considered.

[TehWardy]

Mines complaining that the version needs to be v9.0.1 as i'm using .Net 4.6, I looked in to migrating to .Net Core then noticed this.
I don't understand why this need to be so specific ... given the nature of the assembly in question this is basically going to force my whole code base to take an out of date dependency even if i rely on the latest version of .Net.

This is poor design and MS does this throughout it's code base causing the age old java problem of "dll hell" in our code.

Why force this MS??

It gets worse if you consume multiple MS libs, check this out ...

• Using version 2.* of ASP.NET Core
• Create a new project, and add references to AspNet Core, the Azure Fluent API, and Newtonsoft.Json (as an example, these are pretty common references that people will have)
• Complile the project
• Witness the warning spam all over VS Error List window.

.. Microsoft needs to stop forcing old dependencies full stop or consider that it's libs won't just be used on their own and thus have it's frameworks tested against each other as it's forcing us to have code in production that "may not behave as expected" due to crap like ...

Found Conflicts between versions of <insert virtually any lib from .Net of any .Net SDK here>

... valid warnings so why doesn't anyone do anything about it at MS?

I complained about this here dotnet/aspnetcore#9022 ... apparently i'm told these warnings are valid and that I should just fix them.

Maybe you guys would care to explain how we go about fixing them?

[metrodeveloper]

I totally agree with above comments. Unless you are telling Azure Function developers to seek different platform, MS should really fix the problem. I have a number of 3rd party .net framework libraries that do not use .net Core and they can't be used in Azure Function V1 because of JSON.NET=9.01

[kevin-secrist]

For what it's worth, I was able to use Json.NET 12.x with functions v1 with a binding redirect and it mostly was working fine. I did lose some native serialization/deserialization support with bindings, so I had to do that directly but the project did compile and run properly. You can see how to set up a binding redirect here. Still not the best solution though.

However, as mentioned above I tried to pull in a dependency on Microsoft.AspNetCore.Authorization and (if I remember correctly) it seemed provably impossible to get working properly due to the v1 runtime's hard dependency on Microsoft.Extensions.Logging.Abstractions = 1.1.1. This might have been exarcerbated by our app requiring Microsoft.Extensions.Configuration.AzureKeyVault >= 1.0.2. You either get a working app with no logging, or you don't get a working app. As far as I can tell though that's a separate issue from this, and is alleviated by migrating to functions v2 where the runtime's dependencies are less comingled with the app's dependencies.

I solved that by porting to functions v2 (last week or so), but I still had that transitive dependency on Json.NET 12.x. I got this at compile-time.

Since it was in a package under our control, I just loosened the dependency and downgraded to Json.NET 11.x instead and that's our current state. I didn't investigate any further though - at that point I didn't want to spend any more time on it because I had already wasted more than a day trying to get Microsoft.AspNetCore.Authorization working together with functions v1. Another reason I didn't investigate is because I expected that I'd still have an issue with binding serialization, and that's a feature that would be nice to have.

And just to be clear, when I talk about binding problems I mean that serialization and deserialization both technically work, but Json.NET attributes (like JsonProperty or JsonConverter) are not properly respected. Was able to work around some of those issues by using DataContract attributes instead, but that's pretty limited (e.g. there's no JsonConverter equivalent). This is in agreement with what @Carl012 said above.

[AartBluestoke]

@hf-kklein Newtonsoft.Json has released 12.0.2 now, and 12.0.1 has been out for ~5 months, perhaps update your title?

[AartBluestoke]

https://github.com/Azure/azure-functions-vs-build-sdk/milestone/9 has Relax our restrictions on Newtonsoft major versions #304 as a task

[xavierjohn]

The problem also exist on Microsoft.NET.Sdk.Functions -Version 1.0.27

[brandonh-msft]

@fabiocav any update on this?

[gussj]

Same error here. I need to use the latest version of Json. any news?

[codermrrob]

And this is causing issues for me also... this needs to be addressed please as soon as possible. It is a bug and is costing our team time and our business money and also spend more time researching if functions are the right solution for us after all.

[Alezis]

The same for me. I use Newtonsoft.Json.Converters.StringEnumConverter that appears in Newtonsoft Json 12.0.1 and azure functions failed with error : No matching parameterized constructor found for 'Newtonsoft.Json.Converters.StringEnumConverter', even if I added 12.0.1 explicitly to the project.

[mamoorkhan]

can someone please explain why is = and not >= ?

[PureKrome]

@fabiocav or @cgillum - could we please get a status update with this. Even if there's no good news, at least we know how this issue stands with the Azure Functions team.

Please just tick one of the three options ... it will take you a second...

• We think this issue is important and we are currently trying to get a fix resolved.
• We think this issue is important but it's not important in the short term. It's not yet planned.
• We don't think this issue is a problem so we're not going to do anything.

thank you kindly, AzF team 🍰

[kipergil]

Guys any update on this ? Will be glad if you fix it.

[pksorensen]

This is the most annoying thing that keeps coming back to annoy me on Azure functions at this point.

[kipergil]

Did someone find a workaround for this ? (except than lowering the version in other dependent libraries)

[apavelm]

warning NU1608: Detected package version outside of dependency constraint: Microsoft.NET.Sdk.Functions 1.0.29 requires Newtonsoft.Json (= 11.0.2) but version Newtonsoft.Json 12.0.2 was resolved.

A half year elapsed, but the issue is still actual!

This is a quick fix, please do it

[graham-saunders]

@fabiocav

For the issues reported with 1.x: There's no plan to update the version used by Azure Functions 1.x. There is some documented guidance on how different versions can be used outside of the scope of a binding, but the other scenarios, an upgrade to 2.x is the recommended approach

Can you please give the references on how to work around this in 1.X because we can't seem to find a workaround. We're using 1.X with Microsoft.Azure.Search which requires Newtonsoft >= 10.0.3, but since functions is hardcoded to 9.0.1 it's not compatible. I have newtonsoft 10.0.3 manually installed but it's still not compatible in functions.

Please point us to the documented guidance mentioned

[metro-mark]

what you are doing I think is not in harmony with the effort of Microsoft of continue improving .net framework. MS has stated in .net conference that .net framework would continue to be improved. your 1.x function is based on .net and 2.x is on .net core. you have no idea how difficult it is for many developers and third party vendors to just roll out .net core SDKs. I really would appreciate putting effort to rethink your decision. Sunsetting policy that has gone on for years in Microsoft is what has turned many developers away from Microsoft stack for good. Please do not repeat the bad history. Try to learn from it and ask MS for more funding so that you can rebuild 1.X function.

[AartBluestoke]

@Areson referring to Azure/azure-functions-vs-build-sdk#304 (comment) this is intended behaviour

A specific version chosen by azure functions is physically loaded at runtime prior to your function being loaded. .Net does not allow 2 versions of the same dll to be present at the same time. the 'Equals' dependency was a reflection of this.

Changing to be a '>x' dependency only allows your code to compile, it doesn't mean that it will actually run in azure if you depend on features only available in newer versions, because the newer library is physically not present (as you have noted).

[Areson]

@AartBluestoke Understood. That does seem to make this particular issue seem somewhat useless then. Even with change in the beta package folks won't get the functionality they intended by using it, as the older version will always be loaded. Having the '>x' dependency in there will likely cause confusion as people may expect it to use a newer version and may not think to check the loaded assemblies if everything looks OK. That being said, I appreciate having my code at least compile because in my case I was able to work around this for the time being.

EDIT: Annnnd I read the link to the other issue after posting this.

[b099l3]

Updating to Microsoft.NET.Sdk.Functions 1.0.30-beta1 as @fabiocav said worked for me!

[NickDarvey]

I'm running into issues with this locally when running using func.exe.

I can see Microsoft.NET.Sdk.Functions 1.0.30-beta2 depends on Newtonsoft.Json 12.02 which would work for me, but when debugging my Azure Functions app I can see via 'Modules' that it's pulling in Newtonsoft.Json 11.00.2.21924 from C:\Users\me\AppData\Local\AzureFunctionsTools\Releases\2.42.0\cli_x64\Newtonsoft.Json.dll. At runtime, I'm getting a MissingMethodException.

Given the number of people experiencing issues here, is there any chance Newtonsoft.Json could be removed as a dependency? Could the automagic deserialization into objects be provided by a separate package so people who need to use different versions would have a workaround? (It could even included by default in project templates.)

It seems there is (and has been) quite a few long-open assembly loading issues with Azure Functions, perhaps the a different approach to hosting .NET functions is warranted.

System Info

Azure Functions Core Tools (2.7.1846 Commit hash: 458c671341fda1c52bd46e1aa8943cb26e467830)
Function Runtime Version: 2.0.12858.0

If it's relevant to someone Googling, this is the exception I get:

System.MissingMethodException: 'Method not found: 'System.String Newtonsoft.Json.JsonSerializationException.get_Path()'.'

Workaround

Overwrite the version of Newtonsoft.Json in %localappdata%\AzureFunctionsTools\Releases\2.42.0\cli_x64 with the one you want.

[IanKemp]

Given the number of people experiencing issues here, is there any chance Newtonsoft.Json could be removed as a dependency? Could the automagic deserialization into objects be provided by a separate package so people who need to use different versions would have a workaround? (It could even included by default in project templates.)

This is what Microsoft has done for .NET Core 3.0 with the System.Text.Json namespace/package. That package is backwards-compatible to .NET Standard 2.0 which is what azure-functions-host uses, so I see no good reason why this project simply can't switch from a dependency on Newtonsoft.Json to a dependency on System.Text.Json.

More to the point, I don't understand why this hasn't already been done - instead it seems like the azure-functions-host maintainers are content to dick around with Newtonsoft.Json until the end of time. Kinda makes you wonder exactly how much priority MS is allocating to Azure...

[metro-mark]

@fabiocav not only me but there are still many others that develops using .net framework and even at Ignite today the CEO has praised the efforts of Azure Function. why not just build a better product to support to support both .Net and .Net Core instead of just stating there was a lesson learned and sunset any updates effort towards 1.x?

[fabiocav]

@IanKemp quick comment here to provide an update while I'm out of office to make sure the answer is not delayed. While removing the dependency from the current version may sound trivial, there is a fair amount of work particularly to ensure we're not introducing breaking changes and impacting production apps. This is something we want to do, it just needs to be done carefully. I'm opening issue to track the host work #5203 (for others, it's important to understand that the recommendation above still applies for many scenarios where a version update is required).

[jeffhollan]

Moving the P1 flag over to the related item that @fabiocav created. Will let him update as I believe the main item that this issue was created for has been addressed but additional improvements are being tracked

[GregTerrell]

Installed version 1.0.30-beta2 of the Microsoft.NET.Sdk.Functions package addressed the warning for my build. I was getting the warning with 1.0.29 with NewtonSoft 12.0.3. (needed >= 12.0.0). Following suggestion from @fabiocav

[jackpoz]

• For the issues reported with 1.x: There's no plan to update the version used by Azure Functions 1.x. There is some documented guidance on how different versions can be used outside of the scope of a binding, but the other scenarios, an upgrade to 2.x is the recommended approach

This is not possible when using Microsoft NuGet package https://www.nuget.org/packages/Microsoft.SharePointOnline.CSOM/ as there is no .NET Core version of that package.

[AartBluestoke]

• For the issues reported with 1.x: There's no plan to update the version used by Azure Functions 1.x. There is some documented guidance on how different versions can be used outside of the scope of a binding, but the other scenarios, an upgrade to 2.x is the recommended approach

I have the same issue with interacting with Dynamics CRM -- https://www.nuget.org/packages/Microsoft.CrmSdk.CoreAssemblies/ requires .net framework 4.6.2

When Microsoft hasn't yet upgraded its own packages, it doesn't seem reasonable to assume that the rest of the world is happy/able to upgrade in order to use azure functions 2 and 3.
(i'm willing to, but unable to upgrade because of this dependency)
(edit: november 2020: checking in on this ticket, crm packages still depend on framework, package last updated 2020-09-19)

[ja0b]

2 days ago version 1.0.33 was released but still we see this annoying Newtonsoft.Json (= 9.0.1), I'm having the same issue as @graham-saunders.

As @mamoorkhan pointed out is there any reason for that = there instead of >=.

[mamoorkhan]

@fabiocav and @brandonh-msft any update on this one?

[brandonh-msft]

sorry @mamoorkhan I don't have any power here