Azure-functions-host: 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 https://github.com/aspnet/AspNetCore/issues/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

[fabiocav]

There's a mix of issues reported here, so I wanted to comment on what I'm seeing and make sure we're using this GitHub issue to track the right thing.

• 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

• For the issues with the Microsoft.NET.Sdk.Functions

  • We're relaxing the restriction on the dependency (this will be going out with the next update). In the meantime, explicit references to the package will allow you to workaround conflicts with other dependencies (https://github.com/Azure/azure-functions-vs-build-sdk/issues/304)
  • I see a couple of reports of metadata generation failure during the build process and wanted to confirm this is in the context of V1 only (@kevin-secrist , that's primarily the issue you're reported. If this is in V2, can you please provide a repro or more details on how you had your project/references setup?)

• For runtime binding behavior in 2.x: Currently, the runtime unifies (Json.NET specifically) to the version it uses (currently, 11.x), which enables redirection and is only problematic in the cases where functions or dependencies take a dependency on new functionality (which is the case for some of the issues reported above). We're tracking a fix for this as well, but this last item has to be carefully handled to ensure a good experience and make sure existing apps are not negatively impacted.

[kevin-secrist]

With regards to the metadata generation failure that I received, I'd provide repro details if I had them. I didn't have time to dig further into the issue back when I encountered it. It was on Functions 2.x, but it's possible that it could've been easily solved by something I hadn't tried.

I can provide what I remember at a higher level though in terms of what references that packages had

Main project

• Functions SDK
• Common Internal Library (below)
• Json.NET =11.0.2
• Several Microsoft.Extensions.* 2.x
• A few Microsoft.Azure.WebJobs.* 3.x
• Microsoft.Extensions.Configuration.Json 2.x (requires Json.NET >=11.0.2)

Common Internal Library

• Additional internal libraries that references Json.NET =11.0.2
• An internal library that references Json.NET >= 12.x (this was later changed to reference =11.0.2 to fix my issue)
• A few Microsoft.Azure.WebJobs.* 3.x
• A few Microsoft.Extensions.* 2.x
• Newtonsoft.Json.Schema 3.x
• Microsoft.AspNetCore.Authorization 2.x

However, I've moved past this issue for the most part by using Json.NET =11.0.2 for everything that I can. I'm looking forward to seeing more flexibility in the future though. I have no doubt that this is a pretty tricky and time consuming issue to work through, so thanks for the effort you've been putting in to address it!

[jwisener]

Any ETA on this? We are hitting this issue as well.

[amwayDarshana]

Yes. I have the same issue with azure function v1. I need System.IdentityModel.Tokens.Jwt for token authentication inside azure function project, but it must need Newstonsoft.json version 10.0.0 or more. But my current project not supported new Newtonsoft.json versions?

Any clue how to address this issue.?

System.IdentityModel.Tokens.Jwt
Microsoft.IdentityModel.Protocols
Microsoft.IdentityModel.Protocols.OpenIdConnect
Microsoft.IdentityModel.Logging
Microsoft.IdentityModel.Tokens

All upper mentioned libraries have dependencies with Newtonsoft.json version 10 or more.

[danielkboyer]

I am having the same problem.... I can't drop down to Newtonsoft.Json ( = 9.0.1) as have I have a dependency that uses a much higher library. Is there a work around to this?

[amwayDarshana]

@danielkboyer what is the library that require higher newtonsoft json?

My workaround related to this issue.
I solved this problem without upgrading newtonsoft version.
I have to use jwt Okta token authentication in azure function and I need Microsoft.IdentityModel.Protocols.OpenIdConnect version 5. So it required newtonsoft version 11 which I cannot use in azure function V1.

Solution is use Microsoft.IdentityModel.Protocols.OpenIdConnect version 2.1.5 something. I cannot remember exact, this does not required newtonsoft 11. And I successfully implemented token authentication in azure function.

Try your luck with old version of nuget packages. you may have chance to meet your requirement.

Thank you.

[danielkboyer]

Hi @amwayDarshana I am using the Azure Data Factory library, I was able to solve my issue by downgrading my newtonsoft to 10.0.3. That version satisfies both the data factories needs and the azure function (Even though it says that it needs 9.0.1).

[TehWardy]

@amwayDarshana given the references you're talking about there that's not a solution, you just injected a security risk in to your code base.

I have found however that this is a warning, if you directly reference in the root level project (like an app) the latest version, it'll override the others and force the entire code stack for the app to use the version you reference.

It might result in some edge cases for some dependencies breaking but given how edge those cases are i'd be surprised if most code bases came across them at all.

You'd still get the warning but everything should build and run fine (that's how i've worked around it at least).

[dnetguru]

Any updates?

[jwisener]

Any updates?

[caviyacht]

I see that there is a prerelease version now, 1.0.30-beta1, posted on August 6th. I know that was only two days ago, but what does the timeline for this look like? We are in the middle of an upgrade and really need this.

[adrianknight89]

Still no fix after all these months. Does MS not care about the issue? Clearly, a lot of people need this fixed.

[minhhungit]

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.

Sep 2019 and still getting it

[fabiocav]

@minhhungit can you please try with Microsoft.NET.Sdk.Functions 1.0.30-beta1?

[minhhungit]

@fabiocav

Microsoft.NET.Sdk.Functions 1.0.30-beta1

the warning about newtonsoft.json was gone but I got some new error/warning, not sure why

---

Severity    Code    Description Project File    Line    Suppression State
Error       System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Runtime, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at System.Reflection.RuntimeAssembly.GetExportedTypes(RuntimeAssembly assembly, ObjectHandleOnStack retTypes)
   at System.Reflection.RuntimeAssembly.GetExportedTypes()
   at MakeFunctionJson.FunctionJsonConverter.TryGenerateFunctionJsons()
   at MakeFunctionJson.FunctionJsonConverter.TryRun()

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

Error generating functions metadata
C:\Users\admin\.nuget\packages\microsoft.net.sdk.functions\1.0.30-beta1\build\netstandard1.0\Microsoft.NET.Sdk.Functions.Build.targets  41  
Error       Metadata generation failed. C:\Users\admin\.nuget\packages\microsoft.net.sdk.functions\1.0.30-beta1\build\netstandard1.0\Microsoft.NET.Sdk.Functions.Build.targets  41  
Warning MSB4011 "C:\Program Files\dotnet\sdk\2.2.300\Sdks\Microsoft.NET.Sdk.Publish\Sdk\Sdk.props" cannot be imported again. It was already imported at "C:\Users\admin\.nuget\packages\microsoft.net.sdk.functions\1.0.30-beta1\build\netstandard1.0\Microsoft.NET.Sdk.Functions.Publish.props (13,3)". This is most likely a build authoring error. This subsequent import will be ignored.
Warning MSB4011 "C:\Program Files\dotnet\sdk\2.2.300\Sdks\Microsoft.NET.Sdk.Publish\Sdk\Sdk.targets" cannot be imported again. It was already imported at "C:\Users\admin\.nuget\packages\microsoft.net.sdk.functions\1.0.30-beta1\build\netstandard1.0\Microsoft.NET.Sdk.Functions.Publish.targets (14,3)". This is most likely a build authoring error. This subsequent import will be ignored. 

[Areson]

@fabiocav I updated to the beta. I've got a explicit dependency in my project for version 12.0.2, but when executing I can see the version of the assembly that is loaded is coming from AzureFunctionTools, which is still 11.0.2.

[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 https://github.com/Azure/azure-functions-vs-build-sdk/issues/304#issuecomment-507477114 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 https://github.com/Azure/azure-functions-host/issues/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