Функции 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
}

в первую очередь потому, что он содержит много удобных метаданных, и я cba менять подпись каждый раз, когда решаю, что хочу что-то другое.Кроме того, поскольку, как показывает приведенный выше пример, получить тело довольно просто.

Тем не менее, кажется, что любая из готовых настроек, которые у меня есть, просто взбешена этой идеей.Я хочу, чтобы я:

    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 в подписи облегчает эту задачу.Я пропускаю опцию конфигурации или что-то?

Answer 1

Это связано с неисправной проблемой совместимости проводов .Если ваш исходный код создает BrokeredMessage с использованием конструктора, который принимает объект, а не поток, это приведет к сбою нового клиента .NET Standard.Если для извлечения тела не используется метод расширения, который, как я полагаю, не подходит для функций Azure.

Если у вас есть возможность обновить и повторно развернуть отправителей / издателей, вы могли бы измените способ создания своих сообщений, отправив MemoryStream с байтами, чтобы функция смогла их обработать.

Answer 2

Здесь - это информация из документации по триггеру служебной шины функций Azure о том, что сообщение служебной шины в функциях Azure V2 поддерживает Meessage вместо BrokeredMessage.

Answer 3

Функции Azure v2 больше не используют BrokeredMessage, вместо них используется Microsoft.Azure.ServiceBus.Message .