Azure Functions v2 BrokeredMessage 作为来自 ServiceBus 的输入

Question

我正在关注一个针对 v1 函数的示例，而我想要从中获得的东西我无法在 v2 中复制。

我想要 Azure 函数签名中的 BrokeredMessage。

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 的 BODY 反序列化为 BrokeredMessage！
是什么赋予了？我读过一些文章，指出将 BrokeredMessage 放在签名中会使这些事情变得容易。我是否缺少配置选项或smth？

Answer 1

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

Answer 2

Here 是 Azure Functions 服务总线触发器文档中的信息，说明 Azure Functions V2 中的服务总线消息支持Meessage 而不是BrokeredMessage。

Answer 3

这与损坏的wire compatibility issue 有关。 如果您的原始代码使用接受对象而不是流的构造函数构造 BrokeredMessage，这将导致新的 .NET Standard 客户端失败。除非使用扩展方法来检索正文，否则我认为 Azure Functions 不会这样做。

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