Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

newtonsoft json version is = not >= : when are you going to fix this? #266

Closed
wpqs opened this issue Dec 9, 2018 · 10 comments
Closed

newtonsoft json version is = not >= : when are you going to fix this? #266

wpqs opened this issue Dec 9, 2018 · 10 comments

Comments

@wpqs
Copy link

wpqs commented Dec 9, 2018

There have numerous complaints about newtonsoft json version is = not >= and finally the team accepted that they would address the issue in the next release - see close of issue 259. Please would you give an update on when we might expect such a release to be published as stable? It would be great if the team would also give a commitment that they will NEVER again publish anything with such a constraining dependency.

@provanguard
Copy link

We have the same issue. We cannot update our projects to the latest netwonsoft json because of this strange dependency constraint. When can we expect a new version with this problem fixed?

@vijayrkn
Copy link
Collaborator

vijayrkn commented Feb 4, 2019

@jeffputz
Copy link

I'll pile on here. Being locked into a specific version is a little gross, considering how widely used this package is in, pretty much everything. I'm not sure why you would bind to a queue using JObject and not a string. Then you can use whatever deserializer you want, and frankly in almost every case I'm going to use JsonConvert.Deserialize<T>() anyway. Even the templates are binding to a string.

I get the reason behind the decision, but it's likely not a primary use case or a good design decision to hold consumers to a specific Newtonsoft.JSON version when it's so widely used.

@brandonh-msft
Copy link
Member

@vijayrkn any update?

@vijayrkn
Copy link
Collaborator

vijayrkn commented May 9, 2019

This is a functions runtime issue.

@fabiocav / @ColbyTresness may have inputs on this.

@brandonh-msft
Copy link
Member

fair enough - can we get it moved to the right place so it's triaged/backlogged appropriately? is this issue the effective dupe for runtime?

@vijayrkn
Copy link
Collaborator

vijayrkn commented May 9, 2019

@brandonh-msft - There might be a tooling update to fix up the Newtonsoft.json version set in the targets used once runtime fixes this. So cant say it is completely a dupe but dependent on the runtime fix.

@brandonh-msft
Copy link
Member

ok yes would be really good to get some clarity here because I thought we fixed all this when we shipped Azure/azure-functions-host#992

@ColbyTresness
Copy link

@soninaren to take a look as well.

@fabiocav
Copy link
Member

fabiocav commented May 9, 2019

@brandonh-msft this is not related to the tracked by that issue.

We're currently tracking this work here: #304 and should have it done this sprint.

I'll close this as a duplicate of #304 , so please follow that issue for updates.

@fabiocav fabiocav closed this as completed May 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants