Newtonsoft.Json 参考抱怨 Azure Functions [英] Newtonsoft.Json reference complaining on Azure Functions

问题描述

我正在运行一个名为 SmsWebhook 的 Azure Functions.它调用外部程序集 AzureFunctionsSample.Services.dll 中的一个方法，该方法引用了 Newtonsoft.Json 8.0.3

I'm running an Azure Functions, called SmsWebhook. It calls a method in an external assembly, AzureFunctionsSample.Services.dll that has a reference to Newtonsoft.Json 8.0.3

我的 Run.csx 的详细信息如下:

The details of my Run.csx looks like:

#r "AzureFunctionsSample.Services.dll"
using System.Net;
using AzureFunctionsSample.Services

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)
{
    ...
}

在上面的Run()方法中，我创建了一个实例，并在实例中调用了一个方法.但是，每当我调用该方法时，都会收到以下错误:

Within the Run() method above, I create an instance and call a method in the instance. However, whenever I call that method, I receive the following error:

2016-05-19T13:41:45  Welcome, you are now connected to log-streaming service.
2016-05-19T13:41:46.878 Function started (Id=64fccf0c-d0ef-45ef-ac1c-7736adc94566)
2016-05-19T13:41:46.878 C# HTTP trigger function processed a request. RequestUri=https://ase-dev-fn-demo.azurewebsites.net/api/smswebhook
2016-05-19T13:41:46.878 Function completed (Failure, Id=64fccf0c-d0ef-45ef-ac1c-7736adc94566)
2016-05-19T13:41:46.894 Exception while executing function: Functions.SmsWebhook. Microsoft.Azure.WebJobs.Script: One or more errors occurred. AzureFunctionsSample.Services: Could not load file or assembly 'Newtonsoft.Json, Version=8.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040).

我在bin目录下手动添加了相同版本的Newtonsoft.Json.dll，但还是报同样的错误.为什么它在 Newtonsoft.Json.dll 文件中抱怨?

I manually added the same version of Newtonsoft.Json.dll under the bin directory, but still got the same error. Why is it complaining at the Newtonsoft.Json.dll file?

如果我将外部程序集中的所有逻辑都移到 Run.csx 中，顺便说一句，它不会抱怨.

If I move all the logics within the external assembly into the Run.csx, it won't complain, by the way.

推荐答案

@JustInChronicles，我在这里添加这个作为参考的答案，但预期的行为应该是私有程序集的间接依赖关系是从你的 bin 文件夹，如预期的那样.

@JustInChronicles, I'm adding this here as an answer for reference, but the expected behavior should be that indirect dependencies of private assemblies are resolved from your bin folder, as expected.

我汇总了以下测试来重现您的场景:

I put together the following test to reproduce your scenario:

• 创建了一个简单类型的简单类库，该类库使用 Json.NET 序列化对象并返回 JSON 字符串.此程序集引用 Json.NET 8.0.3.结果包括它正在使用的 Json.NET 程序集版本
• 创建了一个函数，该函数使用 #r "DependencyWithJsonRef.dll" 引用该类型 only，并返回上述方法产生的结果
• 将 DependencyWithJsonRef.dll 和 Newtonsoft.Json.dll (8.0.3) 部署到我的函数的 bin 文件夹

• Created a simple class library with a simple type that uses Json.NET to serialize an object and return the JSON string. This assembly references Json.NET 8.0.3. The result includes the Json.NET assembly version it is using
• Created a function that references that type only with a #r "DependencyWithJsonRef.dll" and returns the result produced by the method mentioned above
• Deployed DependencyWithJsonRef.dll and Newtonsoft.Json.dll (8.0.3) to my function's bin folder

调用函数会产生预期的结果.

Invoking the function produces the expected result.

这里是函数，供参考:

#r "DependencyWithJsonRef.dll"

using System.Net;

public static string Run(HttpRequestMessage req, TraceWriter log)
{
    var myType = new DependencyWithJsonRef.TestType();
    return myType.GetFromJson();
}

如您所见，不需要显式引用间接依赖项 (Json.NET).

As you can see, no explicit reference to indirect dependencies (Json.NET) required.

这是我得到的输出:

{
    "Prop1":"Test",
    "Prop2":1,
    "AssemblyName": "Newtonsoft.Json, Version=8.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed"
}

快速说明:您可能需要检查一件事，特别是如果您在开发函数时更新了该依赖项，即没有缓存程序集结果结果.确保您从零开始的一个可靠方法是(在部署函数和程序集之后)转到 Kudu 并终止 non-scm w3wp 进程，看看是否有帮助.我很想知道这是否有效，因为如果有效，我们可以采取一些措施来改进它.

Quick note: One thing you may want to check, particularly if you've updated that dependency while developing your function is that assembly resultion results were not cached. A sure way to make sure you're starting with a clean slate is to (after you deploy your function and assemblies) go to Kudu and kill the non-scm w3wp process to see if that helps. I'd be curious to know if that does the trick as there are a few things we can to to improve this if it does.

这篇关于Newtonsoft.Json 参考抱怨 Azure Functions的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！