Dependency on specific Newtonsoft.Json package version = 9.0.1 #107
Comments
|
I'm having the same problem, be nice to get this fixed. |
|
This is caused by line 39 in csproj: Why require a specific Json.NET version? Why not : ? |
|
Affected too, need to use Refit which has a dependency on v10.0.3 |
|
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? |
|
/cc @fabiocav |
|
That's correct. This, in the context of functions, prevents some runtime failures. |
|
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. |
|
+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. |
|
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. |
|
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? |
|
https://github.com/dotnetsheff/dotnetsheff-api has this problem, it uses AlexaSkillsKit.NET/ which has a dependencies on
It also uses Refit which has dependencies on
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 |
|
Details on this runtime issue would be appreciated, I haven't had any issues so far. |
|
Possible to get an update on removing the hard dependency for version 9.0.1? |
|
I am struggling to set up a function that uses both |
|
@mdsharpe I was running in to that issue too earlier today. I could not update |
|
+1 please fix! |
|
i have the same issue here: |
|
Same here. Please fix this issue. |
|
Bumping as this is a major blocker. |
|
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.... |
|
+1 |
|
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 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. |
|
Thanks, that's very helpful.
…On Tue, Oct 31, 2017, 6:05 PM Fabio Cavalcante ***@***.***> 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
<#107 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAsY5LHI1Mqk-NgsYgFRQhAQT2FILGB1ks5sx6esgaJpZM4PNfav>
.
|
|
@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? |
|
+1 |
|
@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. |
|
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 |
|
I worked around this with a bindingRedirect. Still get warnings on build, but things seem to work. |
|
What injection issues? The core 2 template sets up (and seems to work fine
with) the logger being injected.
FWIW, from the template, I did have to upgrade the functions sdk nuget, and
install the system.runtime nuget to get it to quit falling back to 462.
…On Dec 20, 2017 7:27 AM, "Johann Dirry" ***@***.***> wrote:
@MV10 <https://github.com/mv10> as far as I can tell there are not only
triggers missing, but also some default dependency injections like logging.
Thankfully it's not a bazillion, but a manageable number of missing
triggers. So I guess they will get there within finite time.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#107 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEbovMypQ5iN7_2wpFk7kwI6f4z4wP8ks5tCSd8gaJpZM4PNfav>
.
|
|
@mcbridedm thank you! didn't know there is a template for Azure Functions / Core 2. So far I've tried a manual conversion of an existing project only. will check the template when I find some time. |
|
Make sure you update your vs azure tooling to get access to it.
…On Dec 20, 2017 8:39 AM, "Johann Dirry" ***@***.***> wrote:
@mcbridedm <https://github.com/mcbridedm> thank you! didn't know there is
a template for Azure Functions / Core 2. So far I've tried a manual
conversion of an existing project only. will check the template when I find
some time.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#107 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEbolWbmurwSGj-SVtd2v7-9uBxpvCBks5tCTgtgaJpZM4PNfav>
.
|
|
Could someone from the Azure community please look into/comment on the alpha-package suggestion? @ahmelsayed @vijayrkn |
|
Missed a package in my earlier response to getting core 2 working. Here's
the full set of steps I took from the core2 template to get up and running
without downgrades to 462
Updates
- Azure Functions and Web Jobs Tools 15.0.31201.0 (12/15 release)
- Microsoft.NET.Sdk.Functions 1.0.7
Additional Packages
- System.Runtime 4.3.0
- Microsoft.AspNet.WebApi.Client 5.2.4-alpha1-170218 (feed:
https://www.myget.org/F/aspnetwebstacknightly/api/v3/index.json)
Devin
On Wed, Dec 20, 2017 at 8:41 AM, Devin McBride <devin.mcbride@gmail.com>
wrote:
… Make sure you update your vs azure tooling to get access to it.
On Dec 20, 2017 8:39 AM, "Johann Dirry" ***@***.***> wrote:
> @mcbridedm <https://github.com/mcbridedm> thank you! didn't know there
> is a template for Azure Functions / Core 2. So far I've tried a manual
> conversion of an existing project only. will check the template when I find
> some time.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#107 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAEbolWbmurwSGj-SVtd2v7-9uBxpvCBks5tCTgtgaJpZM4PNfav>
> .
>
|
|
bump |
|
I downgraded my libs to NewtonSoft 9, so I can't reproduce the error right now but the error was a Constructor not found when we run this instruction : The problem only appears when we use a custom serializer. Problem is we need this serializer to handle our data properly in cosmosDb. |
Any update on fixing these "failures at runtime" with up to date versions of the package? So many other things depend on newer versions of Newtonsoft.Json that remaining a major version behind to avoid potential runtime issues isn't viable. I'm excited about using Functions, but this could be a blocker for us. |
|
Could someone from the Azure community please look into/comment on the alpha-package suggestion? @ahmelsayed @vijayrkn |
|
@ultraviola I understand the concern. The issue is that, currently, just pushing the runtime up would be a breaking change for existing customers, and that's something that can't happen. The next version of Azure Functions will have options to remove those limitations. Does the recommendation to add an explicit reference not work for your scenario? |
|
@fabiocav Can you point to an example of a breaking change that would result from upgrading the Newtonsoft.Json dependency? There's so much heat from this affecting us on this that something really has to be done. I also tried cloning and building the libraries locally, with the intent of fixing this myself. However, everything compiled and ran successfully without any code changes from the current HEAD as far as I can tell. The only problem I faced was that all the nice VS Functions Tooling does not seem to work properly without having the NuGet reference. |
|
@fabiocav - So what you're saying is that if we don't use 9.0.1 we might end up with some weird runtime failures (maybe object serialization/deserialization issues with function bindings?). But, If we use a dependency in our function that requires Newtonsoft.Json >=10.0.1 we can explicitly add that package to our functions project anyway at our own risk? The obvious problem I see is that some of our dependencies may have legitimate requirements for >=10.0.1 and that we essentially have to either jettison Azure Functions, or our dependencies to make everyone happy. Kind of a rock & hard place issue for us. BTW - We are using full .NetFramework, not core or standard. |
|
Why is this such an issue for Functions for not for Webjobs? What’s the difference? |
|
@BowserKingKoopa I think it's the MSBuild Task that generates the function.json files. |
|
It just got more annoying for me:
Repeat several times per day until Package Y is fully developed. |
|
+1 |
|
Please fix it. We are also facing this issue in our project. |
|
I am also facing this issue, I think: https://stackoverflow.com/questions/48650419/could-not-load-file-or-assembly-the-system-cannot-find-the-file-specified. If I downgrade to 1.0.0-alpha6 with nuget, then the templates/tooling is no good. |
|
I pulled down the 1.0.8 version of the library today and still see the issue. |
|
I get this error when I attempt to install the latest WindowsAzure.Storage package to my Azure Functions project. Additionally, if I attempt the rebinding trick, it will compile, but the function will not execute, providing only the obscure status 500 message, "An error has occurred. For more information, please check the logs for error ID..." |
|
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. I am going to cross post this in that library as well in the hopes that someone works to resolve this. One suggestion might be to offer a version 2.0-alpha that eliminates this dependency. |
|
as mentioned in this issue, please add a direct dependency on which ever version of Newtonsoft.Json you want explicitly to your project and you should not have an issue. The error is only there for transit dependencies to warn you that you may get unexpected behavior if you rely on binding types from the different version of the assembly. Other than that, you should be able to use the versions you directly specify in your csproj. I'll close this issue since I don't believe there is a plan for this build task to remove this dependency. Please open an issue on https://github.com/Azure/azure-functions-host to discuss design change in the runtime to not depend on these assembly versions. This repo is just for a build task that glues everything together, but the requirement doesn't come from the task itself. |
|
Has this been released to NuGet yet? |
|
What has? This issue was closed as 'by design' |
|
NewtonSoft released v11 recently, anyone got a chance to test the newest version? |
So, we might get unexpected results, if we use a newer assembly? Or, wait, are you saying to ignore this warning because we won't actually get unexpected results? If we won't actually encounter unexpected results by using the latest version, then why can't the dependency requirements be opened up to allow latest versions of NewtonSoft? This seems like a catch-22 that really should be resolved by now. |
and others
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?
The text was updated successfully, but these errors were encountered: