Azure-functions-vs-build-sdk: 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 [email protected] 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 [e-mail]
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" [e-mail] 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.

<ItemGroup> <PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="2.0.0" /> <PackageReference Include="Microsoft.Extensions.Configuration.EnvironmentVariables" Version="2.0.0" /> <PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="2.0.0" /> <PackageReference Include="Microsoft.IdentityModel.Clients.ActiveDirectory" Version="3.12.0" /> <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.6" /> <PackageReference Include="Newtonsoft.Json" Version="10.0.1" /> </ItemGroup>

[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" [e-mail] 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
.

[rifaterdemsahin]

1.0.7 also does not do the full update from the nuget? Which .json.net should we fix it?

[NicolasRiou]

We're affected too. The problem occurs at runtime so if this was done to avoid runtime failure, i'm afraid the goal wasn't reached. Please add support for NewtonSoft 10

[systemidx]

Also stuck. Project Oxford uses >10.0. Would really really rather not roll back to 1.0.0-a6.

[oxozle]

Come on... Why there is an error like this in big project?

[mcbridedm]

Just curious what error at runtime you are seeing?

I noticed that the vs tooling was recent updated to support core, so I'm in
the midst of updating our functions to use core and am getting passed the
newtonsoft issue in this way. Seems odd this has to be my resolution
though.

Devin

On Dec 16, 2017 10:32 AM, "Dmitriy" [e-mail] wrote:

Come on... Why there is an error like this in big project?

—
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-352201778,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEbohhS-EDcxrxwSma6dn8qv5NP3HU8ks5tBAypgaJpZM4PNfav
.

[oxozle]

Just curious what error at runtime you are seeing?

I have no errors in runtime. I have to downgrade to 9.0.1 and separate project with azure sdk. Now I have 2 side projects. That's why i am crying.

[mcbridedm]

Ahh sorry this was for Nicolas.

On Dec 16, 2017 10:55 AM, "Dmitriy" [e-mail] wrote:

Just curious what error at runtime you are seeing?

I have no errors in runtime. I have to downgrade to 9.0.1 and separate
project with azure sdk. Now I have 2 side projects. That's why i am crying.

—
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-352203457,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEbomQvy77rTk-2T1l9RYFdf_x9d6cIks5tBBIzgaJpZM4PNfav
.

[pankajtakawale]

+1 please fix

[MV10]

Switching to the netstandard version isn't an option if you need any of the bazillion triggers currently missing from that project.

[MovGP0]

@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.

[mcbridedm]

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" [e-mail] 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
https://github.com/Azure/azure-functions-vs-build-sdk/issues/107#issuecomment-353093617,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEbovMypQ5iN7_2wpFk7kwI6f4z4wP8ks5tCSd8gaJpZM4PNfav
.

[MovGP0]

@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.

[mcbridedm]

Make sure you update your vs azure tooling to get access to it.

On Dec 20, 2017 8:39 AM, "Johann Dirry" [e-mail] 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
https://github.com/Azure/azure-functions-vs-build-sdk/issues/107#issuecomment-353114602,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEbolWbmurwSGj-SVtd2v7-9uBxpvCBks5tCTgtgaJpZM4PNfav
.

[jansoren]

Could someone from the Azure community please look into/comment on the alpha-package suggestion? @ahmelsayed @vijayrkn

[mcbridedm]

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 [e-mail]
wrote:

Make sure you update your vs azure tooling to get access to it.

On Dec 20, 2017 8:39 AM, "Johann Dirry" [e-mail] 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
https://github.com/Azure/azure-functions-vs-build-sdk/issues/107#issuecomment-353114602,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEbolWbmurwSGj-SVtd2v7-9uBxpvCBks5tCTgtgaJpZM4PNfav
.

[jansoren]

bump

[NicolasRiou]

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 :
_documentClient = new DocumentClient(settings.EndPoint, settings.AccessKey, GetJsonSerializerSettings(), GetConnectionPolicy(), GetConsistencyLevel())

The problem only appears when we use a custom serializer. Problem is we need this serializer to handle our data properly in cosmosDb.

[ultraviola]

@fabiocav

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

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.

[jansoren]

Could someone from the Azure community please look into/comment on the alpha-package suggestion? @ahmelsayed @vijayrkn

[fabiocav]

@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?

[jboarman]

@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.

[pseabury]

@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.

[BowserKingKoopa]

Why is this such an issue for Functions for not for Webjobs? What’s the difference?

[kevbite]

@BowserKingKoopa I think it's the MSBuild Task that generates the function.json files.

[MV10]

It just got more annoying for me:

1. New Functions app
2. Manually upgrade to JSON 10
3. Add Package X that needs JSON 10
4. Add Package Y that refs WebJobs ... fail
5. Remove Package X
6. Remove JSON 10
7. Add Package Y
8. Re-add JSON 10
9. Re-add Package X

Repeat several times per day until Package Y is fully developed.
_So_ wish I could switch to netcore right now...

[shyamal890]

+1

[gurmitteotia]

Please fix it. We are also facing this issue in our project.

[mgroves]

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.

[scottrudy]

I pulled down the 1.0.8 version of the library today and still see the issue.

[bobmclaren]

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..."

[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. 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.

[ahmelsayed]

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.

/cc @fabiocav @paulbatum @davidebbo

[lorddev]

Has this been released to NuGet yet?

[ahmelsayed]

What has? This issue was closed as 'by design'

[bottomup]

NewtonSoft released v11 recently, anyone got a chance to test the newest version?

[jboarman]

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.

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.