Dependency on specific Newtonsoft.Json package version = 9.0.1

[amit-kumar2]

The latest version 1.0.2 of Microsoft.NET.Sdk.Functions has a specific Newtonsoft.Json package dependency = 9.0.1. The alpha releases supported Newtonsoft.Json (>= 9.0.1). This is causing a Json package version dependency mismatch in our solutions (between other referenced libraries and the functions project) and functions project fails to start since it cannot load 9.0.1 version.

As a workaround, we had to downgrade to 1.0.0-alpha6. Are there any plans to support Newtonsoft.Json (>= 9.0.1) in the upcoming releases of Microsoft.NET.Sdk.Functions?

[kevbite]

I'm having the same problem, be nice to get this fixed. See Stackoverflow Question for more details.

[pkanavos]

This is caused by line 39 in csproj:

<PackageReference Include="Newtonsoft.Json" Version="[9.0.1]" />

Why require a specific Json.NET version? Why not :

<PackageReference Include="Newtonsoft.Json" Version="9.0.1" />

?

[BenWhite27]

Affected too, need to use Refit which has a dependency on v10.0.3

[brettsam]

Hey @lindydonna / @ahmelsayed -- have heard that this can block some customers when building locally. They had to go back to the -alpha build in order to unblock. Is it possible to lift this restriction?

[ahmelsayed]

/cc @fabiocav I thought we added that restriction to fix an issue with people specifying a higher version then getting a runtime error that new methods are not available.

[fabiocav]

That's correct. This, in the context of functions, prevents some runtime failures.

[brettsam]

I think this is the only layer where we prevent this package from moving forward (i.e. -- the runtime lets you do it). In some cases, it seems to work. Since we don't restrict nugets anywhere else, should we relax it here as well?

Side note -- I agree that it's not a great solution either way. Just not sure if we shouldn't get out of people's way here.

[johlrich]

+1 for removing restriction since the other packages don't restrict. I personally haven't had any runtime issues with 10+ (to be fair it's been local development so far for this service).

For me this is an issue since Newtonsoft.Json 9 + F# 4.1 gives runtime exceptions when deserializing to FSharpList types.

[fabiocav]

Unfortunately, removing the restriction, in most cases, would just delay a problem that would now happen at runtime, and often in a way that is hard to identify.

[johlrich]

My only concern is since the other nuget packages don't have this restriction, it's still easy to get a hard to identify runtime scenario that wasn't really defined. Is it possible to share some details or links to the problems seen for those of us willing to brave on so we know what to look out for?

[kevbite]

https://github.com/dotnetsheff/dotnetsheff-api has this problem, it uses AlexaSkillsKit.NET/ which has a dependencies on

BouncyCastle (>= 1.8.1) Microsoft.AspNet.WebApi.Client (>= 5.2.3) Newtonsoft.Json (>= 7.0.1)

It also uses Refit which has dependencies on

Microsoft.AspNetCore.WebUtilities (>= 1.1.2) NETStandard.Library (>= 1.6.1) Newtonsoft.Json (>= 10.0.3) System.Net.Http (>= 4.3.2) System.Text.Encodings.Web (>= 4.4.0)

The only way around this we've found is to reference Refit@3.0.1 which has a dependency of Newtonsoft.Json (>= 9.0.1) then just copy the whole of AlexaSkillsKit.NET from github in to our project dotnetsheff.Api/AlexaSkill/AlexaSkillsKit.Lib

[BenWhite27]

Details on this runtime issue would be appreciated, I haven't had any issues so far.

[mcbridedm]

Possible to get an update on removing the hard dependency for version 9.0.1?

[mdsharpe]

I am struggling to set up a function that uses both Microsoft.NET.Sdk.Functions and Microsoft.Azure.WebJobs.ServiceBus because of this conflict on versions of Newtonsoft.Json.

[leftler]

@mdsharpe I was running in to that issue too earlier today. I could not update Microsoft.Azure.WebJobs.ServiceBus to 2.1.0-beta4, however after removing the nuget package and re-adding it the update worked fine (be sure you have the pre-release box checked in the NuGet manager). Also make sure you remove all other packages that are now dependencies inside of Microsoft.NET.Sdk.Functions (Microsoft.Azure.WebJobs and friends)

[rposener]

+1 please fix!

[MovGP0]

i have the same issue here:

Warning NU1608  Detected package version outside of dependency constraint: Microsoft.NET.Sdk.Functions 1.0.6 requires Newtonsoft.Json (= 9.0.1) but version Newtonsoft.Json 10.0.3 was resolved.    

[ali-kashanian]

Same here. Please fix this issue. I closed issue #132 since it was a duplicate.

[Furynation]

Bumping as this is a major blocker.

[richhosek]

Was able to add the dependencies of the SDK.Function package separately and include the 10.0.3 version of NewtonSoft.Json, but reading about runtime issues has me worried. We have other Core packages that require Json >= 10.0.3. I too would like to hear more about the runtime issues and what needs to be avoided....

[tmgirvin]

+1 Been fighting this for a day trying to find various work-arounds. Please fix.

[fabiocav]

This is locked on 9.0.1 by design to prevent failures at runtime that are often confusing and difficult to diagnose.

The Functions runtime currently binds to 9.0.1 and while some scenarios would work if there's a reference to a higher version, many of the binding scenarios would fail in ways that would cause confuse a large number of customers. Those scenarios are primarily where you'd need to bind to types from one of the assemblies we lock on (e.g. binding to JObject, CloudBlockBlob, etc.), and would typically lead to a type mismatch and failure to index the function.

@richhosek the issue above is the main thing to look for when referencing a higher version of Newtonsoft.Json. If the use of those types is primarily scoped to your function (doesn't involve passing or receiving object of those types to and from bindings), you should be OK. We're investigating a couple of options to unblock users when this wouldn't cause an issue.

We do agree that although this is a behavior that protects some users against confusing runtime failures, it isn't optimal and does block valid scenarios. I had a quick chat with @ahmelsayed and we'll be exploring an approach to give us a good balance and unblock your scenarios.

We appreciate the patience and will keep this issue updated.

[richhosek]

Thanks, that's very helpful.

On Tue, Oct 31, 2017, 6:05 PM Fabio Cavalcante notifications@github.com wrote:

This is locked on 9.0.1 by design to prevent failures at runtime that are often confusing and difficult to diagnose.

The Functions runtime currently binds to 9.0.1 and while some scenarios would work if there's a reference to a higher version, many of the binding scenarios would fail in ways that would cause confuse a large number of customers. Those scenarios are primarily where you'd need to bind to types from one of the assemblies we lock on (e.g. binding to JObject, CloudBlockBlob, etc.), and would typically lead to a type mismatch and failure to index the function.

@richhosek https://github.com/richhosek the issue above is the main thing to look for when referencing a higher version of Newtonsoft.Json. If the use of those types is primarily scoped to your function (doesn't involve passing or receiving object of those types to and from bindings), you should be OK. We're investigating a couple of options to unblock users when this wouldn't cause an issue.

We do agree that although this is a behavior that protects some users against confusing runtime failures, it isn't optimal and does block valid scenarios. I had a quick chat with @ahmelsayed https://github.com/ahmelsayed and we'll be exploring an approach to give us a good balance and unblock your scenarios.

We appreciate the patience and will keep this issue updated.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/Azure/azure-functions-vs-build-sdk/issues/107#issuecomment-340932898, or mute the thread https://github.com/notifications/unsubscribe-auth/AAsY5LHI1Mqk-NgsYgFRQhAQT2FILGB1ks5sx6esgaJpZM4PNfav .

[rposener]

@fabiocav thanks for the idea about how locking it in some perceptions is preventing confusing issues. Problem is that once you reference another project that requires >= 10.0.1 you get a build error and no way around that issue without doing exactly what you think you just prevented. The only work-around in that case is to explicitly add Newtonsoft.Json 10.0.1 or higher, which just forces this package to use it anyway. Locking to a specific lower level is not workable - specifically for a package like Newtonsoft.Json.

Does anyone have a list of what these supposed breaking changes from 9 -> 10? I'm not seeing them on the releases page. Perhaps @JamesNK can point this thread to that list?

[hoshauch]

+1 Been fighting this for a day trying to find various work-arounds. Please fix.

[kevbite]

@hoshauch my workarounds were to just pull down any code that used Newtonsoft.Json and include it all in the project but target the same version of Newtonsoft.Json. Works but is a nasty hack.

[JamesNK]

Does anyone have a list of what these supposed breaking changes from 9 -> 10? I'm not seeing them on the releases page. Perhaps @JamesNK can point this thread to that list?

All the items marked "change"

[rposener]

Thanks @JamesNK! @fabiocav @hoshauch - can you tell us more about which of these specifically broke something for those of us forced to use 10.0.x versions? Maybe also what is broken?

Change - Removed .NET 4 portable class library target from NuGet package Change - Removed obsolete JsonConverter.GetSchema method Change - Removed obsolete constructor from DefaultContractResolver Change - Removed obsolete async methods from JsonConvert Change - Removed obsolete OnDeserialized, OnDeserializing, OnSerialized, OnSerializing, OnError from JsonContract Change - Removed obsolete JsonDictionaryContract.PropertyNameResolver Change - Removed obsolete ConstructorParameters, OverrideConstructor, ParametrizedConstructor from JsonObjectContract Change - Obsoleted TypeNameAssemblyFormat properties on JsonSerializer and JsonSerializerSettings Change - Obsoleted SerializationBinder Change - Obsoleted Binder properties on JsonSerializer and JsonSerializerSettings Change - Obsoleted FormatterAssemblyStyle in non-full .NET targets Change - Obsoleted Newtonsoft.Json.Bson (moved to new NuGet package) Change - Improved constructor parameter binding on .NET Core and portable builds Change - Improved error when attempting to convert root JSON object property to an XML attribute Change - Changed exception thrown when parsing invalid Unicode escape sequence to JsonReaderException Change - Changed StringEnumConverter.AllowIntegerValues to also reject reading integer strings Change - Changed StringEnumConverter.AllowIntegerValues to also reject writing enum values with no name

[mdsharpe]

I worked around this with a bindingRedirect. Still get warnings on build, but things seem to work.

[michelandre]

Newtonsoft is one of the most refrenced packages in nuget apart from Microsoft packages, its unreasonable to hardcode a version dependency for the fact that u might get hard to diagnose runtime errors as it will be blocking referencing another library or anything including newtonsoft.json including prominent microsoft packages.

[chris31389]

Is there any news on this? I am really excited to work with functions, but getting majorly turned off because I can't actually get it building because of this reference conflict.

For me it was when I was trying to use the Microsoft.Extensions.Configuration.Json package (which requires version 10.0.1)

[eralston]

👍 Would appreciate a look

[tmakin]

I've just run into this issue when trying to use a netstandard2.0 library that references the latest Microsoft.Azure.DocumentDB.Core. Downgrading is not really a viable option because everything else in my solution now references Json.NET 10.0.3.

@mdsharpe Are you able to share your binding redirect workaround? According to this thread https://github.com/Azure/azure-webjobs-sdk-script/issues/992 redirects are still not supported so I'm interested to know what you did?

[BowserKingKoopa]

I had to abandon Functions and revert a bunch of stuff back to WebJobs because of this issue, and the lack of binding redirect support in general. Bit of a disaster. Huge waste of time.

[rposener]

@tmakin - the work-around is pretty simple. In a .net core project you can add a reference to this package and the Newtonsoft.Json package version 10.x.x.x - as I understand it, that effectively triggers a binding redirect without explicitly having to set a binding redirect. Here is what comes out in the build as a result:

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

Perhaps someone on the @dotnet team can confirm this is correct / only way around this / until we can convince this team they way everyone else does things is OK.

[Furynation]

What @rposener is how I worked around it as well. I haven't hit any unexpected issues yet...

[chris31389]

@rposener are you able to show an example of a csproj with the references? When I go to add a reference it just projects, assemblies and shared dll's.

[mcbridedm]

This was more difficult for us because we have other core packages where the core model requires 10.0.x (for example System.IdentityModel.Tokens.Jwt) and so we could neither force an up or downgrade.

We ended up having to bag dual targeting and revert our webapi project back to 462, or risk things not working as expected given the compiler warnings. We've opted to just put core on hold for the time being.

On Nov 22, 2017 6:23 AM, "Bob Fury" notifications@github.com wrote:

What @rposener https://github.com/rposener is how I worked around it as well. I haven't hit any unexpected issues yet...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Azure/azure-functions-vs-build-sdk/issues/107#issuecomment-346363778, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEbov0zqOI3oWMTRO1WBeK8iRmPWqxTks5s5C4LgaJpZM4PNfav .

[rposener]

@chris31389 here are the relevant bits from my .csproj for the function app (which we do target net462 same as @mcbridedm), although our class libraries are netstandard2.0, so we use them in our .net core projects as well.

`

`

[jansoren]

+1 Could you perhaps create an alpha-package using the 10.0.x version of Newtonsoft.Json until the main issue is resolved?

[MovGP0]

@mcbridedm the .NET Standard version of Microsoft.NET.Sdk.Functions already target the newer version of Newtonsoft.Json, since it is the only version that targets .NET Standard.

[adukstad]

An alpha-package with 10.0.x would help moving my project along, is this possible ? If not, when can we expect a fix of this issue ?

[fabiocav]

It's worth mentioning that this should work today with an explicit reference to a newer package version.

[jansoren]

@fabiocav Is explicit reference possible when building in Teamcity?

[Jungers42]

We've also been affected by this. It seems like it would take very little effort to expose an alpha version that does NOT have this safety guard constraint in place. (echoing the same thoughts from above) Would love to have some movement on this. Seems like a large number of people are affected, it would take very little effort to expose an alpha version (used at developers own peril), and folks would love to help out resolving the subtle concerns related to the version conflict to begin with!

[dapug]

Stupid avoidable bug. Let's get a fix pushed out please.

At least your project can compile and run, but the build warning about the dependency constraint is uncool. Plus, I don't like seeing yellow bang in my Solution Explore :).

[hopix]

Affected too. Please fix targeting .NETStandard2.0.

[rifaterdemsahin]

When are we getting the update?

[chris31389]

I've just seen that they have released 1.0.7 with it unchanged. So i'm guessing... not soon.

[mcbridedm]

@MovGP0

You are right. We're stuck using 462 until the vs tooling supports net standard. Maybe this has changed in the last month though.

Devin

On Nov 29, 2017 1:55 AM, "Johann Dirry" notifications@github.com wrote:

@mcbridedm https://github.com/mcbridedm the .NET Standard version of Microsoft.NET.Sdk.Functions already target the newer version of Newtonsoft.Json, since it is the only version that targets .NET Standard.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Azure/azure-functions-vs-build-sdk/issues/107#issuecomment-347809096, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEbovau562bVGOro6hRAj5xZ8jjBBa-ks5s7Sn2gaJpZM4PNfav .