Azure 函数服务总线输出绑定错误

Error with Azure Function Service Bus Output Binding

我在 Azure 服务总线输出绑定方面遇到问题,我不确定如何继续。我没能找到类似的问题,所以如果这是重复的,我深表歉意。

我正在尝试使用本地 VS 2017 开发过程,因此应该会自动生成 function.json 绑定。函数签名如下:

  [FunctionName("RequestNewPaladinInvitation")]
  public static HttpResponseMessage Run(
     [HttpTrigger(AuthorizationLevel.Anonymous, "post")]HttpRequestMessage req,
     [ServiceBus("thequeue")] ICollector<Invitation> invitationOutputQueue,
     TraceWriter log)
  {
     //Do some stuff and write to the queue
     invitationOutputQueue.Add(invite);
  }

我在 运行 本地函数时收到以下错误。

Microsoft.Azure.WebJobs.Host: Error indexing method 'RequestNewPaladinInvitation.Run'. Microsoft.Azure.WebJobs.Host: Cannot bind parameter 'invitationOutputQueue' to type ICollector`1. Make sure the parameter Type is supported by the binding. If you're using binding extensions (e.g. ServiceBus, Timers, etc.) make sure you've called the registration method for the extension(s) in your startup code (e.g. config.UseServiceBus(), config.UseTimers(), etc.). [9/1/2017 5:42:49 PM] Error indexing method 'RequestNewPaladinInvitation.Run'

我的host.json和local.settings.json定义如下:

{
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "<MyStorageAccountInfo>",
      "AzureWebJobsDashboard": "<MyDashboardInfo>",
      "AzureWebJobsServiceBus": "<MyServiceBusConnectionString>"
   }
}

令我印象深刻的是,定义 AzureWebJobsServiceBus 值将使它成为整个函数应用程序中任何 ServiceBus 绑定的默认 ServiceBusAccount。

我还尝试将 ServiceBus 绑定显式指向具有以下替代属性 [ServiceBus("createpaladininvitation",Connection = "ServiceBus")] 的帐户的连接字符串。我对惯例的理解是 属性 的 AzureWebJobs 部分不应包括在内。以防万一我误解了,我也尝试了[ServiceBus("createpaladininvitation",Connection = "AzureWebJobsServiceBus")]。我什至尝试用以下属性 [ServiceBusAccount("ServiceBus")] 来装饰方法和参数。我还尝试了与 ServiceBus 属性的连接参数相同的变体。

在所有情况下,我得到相同的 function.json 输出,显示没有为 ServiceBus 输出绑定生成绑定。

这是function.json:

{
  "generatedBy": "Microsoft.NET.Sdk.Functions-1.0.0.0",
  "configurationSource": "attributes",
  "bindings": [
    {
      "type": "httpTrigger",
      "methods": [
        "post"
      ],
      "authLevel": "anonymous",
      "name": "req"
    }
  ],
  "disabled": false,
  "scriptFile": "..\bin\AzureFunctionsPoc.dll",
  "entryPoint": "AzureFunctionsPoc.RequestNewPaladinInvitation.Run"
}

感觉好像遗漏了一些明显的东西。

[更新]

当我试图继续弄清楚发生了什么时,我在本地 运行 函数并编辑了生成的 function.json 文件并添加了我 认为的绑定 应该已经生成了。手动编辑的结果 function.json 是:

{
  "generatedBy": "Microsoft.NET.Sdk.Functions-1.0.0.0",
  "configurationSource": "attributes",
  "bindings": [
    {
      "type": "httpTrigger",
      "methods": [
        "post"
      ],
      "authLevel": "anonymous",
      "name": "req"
    },
    {
      "type": "serviceBus",
      "name": "invitationOutputQueue",
      "queueName": "createpaladininvitation",
      "connection": "ServiceBus",
      "direction": "out"
    }
  ],
  "disabled": false,
  "scriptFile": "..\bin\AzureFunctionsPoc.dll",
  "entryPoint": "AzureFunctionsPoc.RequestNewPaladinInvitation.Run"
}

通过这些编辑,该方法完全符合预期。

这感觉更像是我遗漏的语法或约定问题,或者工具错误。

目前在 ServiceBus 输出触发器方面存在一个突出的工具错误。如果你 'deploy' 你的应用程序到 Azure Functions,它会起作用,只是不在本地使用工具

请在此处查看相关 GitHub 问题:Service Bus output binding issue

这里:Latest v1.0.0 not working with ServiceBus. alpha 6 still works.

This is related to the lazy load. We're not picking up the service bus extension, hence the indexing error. (Azure/azure-webjobs-sdk-script#1637)

The reason for that is that ServiceBus extension is different than the others. We expect extensions to have a public parameterless config object that implements IExtensionConfigProvider.

SB is internal (https://github.com/Azure/azure-webjobs-sdk/blob/663a508e8a851629c26a51e7de3af36629dfd120/src/Microsoft.Azure.WebJobs.ServiceBus/Config/ServiceBusExtensionConfig.cs#L17 ) so our scan for ExportedTypes misses it (see https://github.com/Azure/azure-webjobs-sdk-script/blob/b1445485807bb190ba0716af1a8dc81a864b5228/src/WebJobs.Script/Host/ScriptHost.cs#L735) . SB's config does not have a parameterless ctor, so the Activator.createInstance call will fail too. This hotfix (which we made to script runtime) Azure/azure-webjobs-sdk-script#1804 would fix it; but that would need to be pulled to CLI.