Azure函数v2 BrokeredMessage作为ServiceBus的输入

Question

我遵循的是一个以v1函数为目标的示例，以及我希望从其中得到的东西--我还无法在v2中进行复制。

我希望BrokeredMessage在Azure函数的签名中。

public static async Task WhatIsTheTime(
            [ServiceBusTrigger(queueName: QueueName, Connection = ConnectionStringKey)]
            BrokeredMessage message, 
            ILogger log)
{
     var myObj = message.GetBody<MyType>();
     // whatever
}

主要是因为它包含了很多方便的元数据，而且每次我决定需要不同的东西时，我都会更改签名。同样，正如上面的例子所示，很容易得到身体。

然而，似乎无论什么开箱即用的设置，我都对这个想法非常愤怒。它想让我做的是：

    public static async Task WhatIsTheTime(
            [ServiceBusTrigger(queueName: QueueName, Connection = ConnectionStringKey)]
            MyType myObj, 
            ILogger log)
{
    // whatever
}

为我迈出第一步。

如果我这样做，一切都是幸福的，我们都可以回家。但是我不想要这个，我宁愿要完整的BrokeredMessage。

无论我如何尝试打包主体的内容，在代码执行之前，它都不幸地失败了，给了我许多不同的错误(取决于我如何打包它)，但很明显，这个错误：

Exception while executing function: Exception binding parameter Expecting element 'BrokeredMessage'   

它试图将BrokeredMessage的主体反序列化为BrokeredMessage！

怎么回事？我读过一篇文章，内容是在签名中加入BrokeredMessage使这件事变得很容易。是缺少配置选项还是smth？

Answer 1

Azure函数v2不再使用BrokeredMessage，而是使用Microsoft.Azure.ServiceBus.Message。

Answer 2

这里是Azure函数服务总线触发器文档中的信息，表示Azure函数V2中的服务总线消息支持Meessage而不是BrokeredMessage。

Answer 3

这与破损的导线兼容性问题有关。如果您的原始代码正在使用接受对象而不是流的构造函数构造BrokeredMessage，这将导致新的.NET标准客户端失败。除非使用扩展方法来检索身体，否则我认为Azure函数不会这样做。

如果您有一个更新和重新部署您的发件人/发布者的选项，您可以通过发送一个带有字节的MemoryStream来更改消息的构造方式，以便该函数能够处理它。