Dependency on specific Newtonsoft.Json package version = 9.0.1

[MV10]

Opening an issue that started in the wrong repo.

Azure/azure-functions-vs-build-sdk#107

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.

[scottrudy]

I spent several days slowly removing code from an Azure Function working with CosmosDB only to find that this is the underlying issue. I have used the binding redirect successfully before, but it did not work for this. All versions of the MicrosoftAzure.CosmosDB.Table library require Newtonsoft.Json >= 10.0.2. When trying the redirect the project compiles, but corrupted data is sent to CosmosDB, so only the PartitionKey, RowKey and TimeStamp show up in the table.

This issue was also noted in the Azure docs: https://docs.microsoft.com/en-us/azure/cosmos-db/table-introduction#comments-container

[pragnagopa]

@ahmelsayed - Can you take a look at this?

[ahmelsayed]

@fabiocav and @paulbatum should be aware of this.

[Jungers42]

I hate to post a comment only to throw shade, but this seems like such a simple issue to resolve (even if the simple solution is only to cause some specific known edge cases to have a runtime issue which could be documented and THEY could be required to back-version) ... and yet I've been watching MONTHS and MONTHS of posts to various threads on this issue only to be blown off, seemingly, by those developers in a position to do something about this! Everyone who is, or has been trying, to actually use Functions has been fighting with this for months! Come on people. Can someone please make a command decision to unblock the world TRYING to use functions and make this work?! Perhaps as an alpha release as many have suggested? Something?!

(Again, sorry for the tone ... but my project has been on hold for doing anything more with functions until this is resolved and I'd really hate to pay the costs, over again, simply to move away from functions after having just gone through the pains to get there!)

[paulbatum]

Please, if you are going to throw some shade on this topic, lets put all of it in one place - the binding redirect thread - #992

Issues with cosmos table API usage from functions is tracked here - #1751

Closing this issue as its covered by the two issues I just linked.

[lorddev]

@paulbatum AFAIK binding redirect is done via web.config or app.config, neither of which work in an Azure Functions app, so why do you want to send us to that thread?

[paulbatum]

@lorddev because we have many different issues filed across our repos that all boil down to the same set of problems around assembly loading/binding. There is not much point of having the same conversation in a bunch of different places. The aspects of this issue that do not relate to assembly loading are covered in the other issue I linked.

[cleverguy25]

Paul, this is not a binding redirect problem, and linking it to that is a mistake. This is a code nuget dependency problem causes by your own SDK. Many Microsoft project fall prey to this with Newtonsoft.Json, many make this same silly decision, and in the end they eventually fix it to open the dependency to all versions (only after pissing off the community for a long time).

I love MSFT tech, and really want functions to work. But my entire team is pushing AWS Lambda because of issues like this.

[paulbatum]

@cleverguy25 The title of #992 is perhaps misleading. The content of the issue is an extensive discussion with the theme of "let me use version X of dependency Y". Hopefully my linking to it makes sense in this context.

If your problem is truly only about the Newtonsoft.Json constraint that the Microsoft.NET.Sdk.Functions package has, then you can unblock yourself by adding an explicit reference to the chosen version of that package. Once you do this, certain features of functions will stop working correctly. For an example of a feature that does not work correctly once you do this, see here.

The same workaround can be used to resolve the situation where you have a dependency that is demanding a new JSON.NET. I have a simplified example of that here. The same caveats apply - some features that require an exchange of types between the functions runtime code and the user code stop working once you do this if those types came from the assembly that you forced to a different version.

If we relaxed the package version constraint, we would have a different github issue opened (rightfully so) by a user complaining that they attempted a NuGet update, NuGet permitted it, and their function app stopped working. So for functions V1, we chose an approach that maximizes the chances of our features working as expected but leaves the door open for the user to unblock themselves (as discussed above).

For functions V2, we are actively working on changes to allow for type unification. This unification should provide users with more flexibility to pick versions of their dependencies without breaking our built in features and once that proves to be the case, we'll start relaxing the version constraints on our dependencies. There's some information on this in #992 and we'll continue to update that issue as we make progress.

We will not be able to introduce these changes into V1 because they would be breaking. Since this issue describes the V1 dependency (Newtonsoft.Json 9.0.1), it remains closed. If you would like, it would be fine to have a separate issue tracking the relaxing of the V2 constraint on Newtonsoft.Json (= 10.0.3). I would mark that issue as blocked, and it would be unblocked once we have completed the work I described above to enable type unification.

[TonyHenrique]

I am having an issue, I added this NuGet , when I run the function I get: Could not find the assembly 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'
Please see DotNet4Neo4j/Neo4jClient#271

[TheCodechimp]

I read #992 and unfortunately it doesn't address my issues. The primary thing I got out of it is V2 is coming, and is going to fix all of this nonsense; but that's not very reassuring when it's still in preview and you could still have further breaking changes. @paulbatum Our team has tried this workaround and it doesn't address our issues because we run into the caveats you mention. We have nuget packages that rely on newtonsoft json 11. As soon as we up the reference in the function, sure it will "work" but it crashes and reports that it can't find dll of a specific version. The team that I'm on has wasted a ton of time dealing with this issue, so is this a we need to stop using Azure until V2 comes out?

[paulbatum]

I think for V1, the information I shared above is up to date and there is not much else to share. For V2 we have completed the work to do type unification and you should find that this issue is not present there. Yes V2 is in preview at this current point of time.

[TheCodechimp]

I don't want to muddy the waters. My point with V2 is that you shouldn't try and sell it as a fix if you're not willing to stand by it. We can't run preview level code in production, nor would I ever advocate for that sort of solution, and that's how it comes across. As far as the information you shared, is it really a fix if it works for some of the people some of the time? When we try your fix, and upgrade nuget packages to the latest, we run into missing dll runtime errors. So we can't upgrade any of our nuget packages, and that means we're really far behind, and in some cases cannot use certain packages with functions; We have to work around a production flaw. I hope you can appreciate how impactful this flaw has been, and how much time we've wasted just working around it, and how the longer there's no real solution, the worse it gets. I could write all day stating how frustrating this has been, and at the same time my previous experiences from devs at microsoft has been, "hey what are you running?" "What's your use case, and how can we help." Usually we either find the flaw in what we were doing, or we learn something about how we can use the system better.

[paulbatum]

Sorry I am just trying to give you the most complete information available. I am a little bit unclear if you there is a specific piece of information you need that you are not getting.

In case you missed it (and because the thread is so long), I want to draw your attention to this comment specifically which talks about why we invested in fixing this in V2 (and not V1):
#992 (comment)

I am not saying that V2 is the fix today (because its in preview). But I'm saying its the only place that there is going to be a fix.

[TheCodechimp]

@paulbatum Yeah, I missed that article, but it's kind of the direction we're forced to go. The drawback is that the Azure functions & tools are far more robust then webjobs.

[metrodeveloper]

This hardly addresses real problems developers have. You are pretty much telling developers to abandon custom .net framework libraries and Azure function v1 if it doesn't work with JSON=9. .net core is not widely received and I hope you understand that this kind of attitude is what moves developers away from using anything Microsoft.

[paulbatum]

As discussed above, we spent time looking for ways to fix this in V1, and the approaches we came up with were breaking changes that would impact existing V1 customers. Therefore we were not able to proceed with those changes. Yes it is unfortunate that V1 was implemented with this limitation. We took our lessons from V1 and applied them to V2.

[metrodeveloper]

If V2 can accommodate .net framework in cojunction with .net core, it would be golden. I am speaking in behalf of so many third party companies that simply won't have the solution available for .net core any time soon. I strongly suggest looking at the issue and instead of abandoning V1 and .net Framework.

[nebosite]

For those who are interested, I wrote a routine to get around dll issues in azure functions. This routine overrides the assembly loader and looks in the $HOME folder for alternate versions. This allows the developer to package the needed version in their functions project.

https://github.com/nebosite/azure-functions-rocketscience/blob/master/src/AFRocketScienceShared/Tools/AssemblyHelper.cs