Разработка устаревших функций библиотеки классов C# с помощью Функции Azure

Внимание

Поддержка будет прекращена для встраиваемой модели 10 ноября 2026 г. Настоятельно рекомендуется перенести приложения в изолированную рабочую модель для полной поддержки.

В этой статье описывается разработка Функции Azure с помощью C# в библиотеках классов .NET. Эти библиотеки классов используются для выполнения в процессе с средой выполнения Функций. Ваши функции .NET могут работать изолированно от среды выполнения Functions runtime, что дает несколько преимуществ. Дополнительные сведения см. в разделе изолированная модель работника. Полное сравнение этих двух моделей см. в разделе "Различия между внутрипроцессной моделью и изолированной рабочей моделью".

Внимание

В этой статье поддерживаются функции библиотеки классов .NET, которые выполняются в процессе с средой выполнения. Функции C# также могут выполняться во внепроцессном режиме и изолированы от среды выполнения функций. Модель изолированного рабочего процесса — единственный способ запуска _non-LTS_ версий приложений .NET и .NET Framework в текущих версиях среды выполнения Functions. Дополнительные сведения см. в статье об изолированных функциях рабочего процесса .NET. Для полного сравнения между изолированным рабочим процессом и внутрипроцессными функциями .NET см. раздел Различия между внутрипроцессными и изолированными рабочими процессами .NET Функции Azure.

В качестве разработчика C# вы также можете быть заинтересованы в одной из следующих статей:

Начало работы	Основные понятия	Интерактивное обучение и примеры
Using Visual Studio Using Visual Studio Code Использование средств командной строки	Параметры размещения Вопросы производительности разработка в Visual Studio Внедрение зависимостей	Создание бессерверных приложений. Примеры C#

Функции Azure поддерживает языки программирования C# и C# Script. Если вы ищете рекомендации по использованию C# в портале Azure, см. справочник разработчика по C# script (.csx).

Поддерживаемые версии

Версии среды выполнения функций поддерживают определенные версии .NET. Дополнительные сведения о версиях Функции Azure см. в разделе Обзор версий среды выполнения Функции Azure. Поддержка версий также зависит от того, выполняются ли функции в процессе или изолированном рабочем процессе.

Примечание.

Чтобы узнать, как изменить версию среды выполнения Функций, используемую приложением-функцией, обратитесь к разделу Просмотр и обновление текущей версии среды выполнения.

В следующей таблице показан самый высокий уровень .NET или .NET Framework, который можно использовать с определенной версией Функций.

Версия среды выполнения функций	Изолированная рабочая модель	Модель в процессе4
Функции версии 4.x1	.NET 105 .NET 9.0 .NET 8.0 .NET Framework 4.82	.NET 8.0
Функции 1.x3	Н/Д	.NET Framework 4.8

¹ .NET 6 ранее поддерживалась в обеих моделях, но достиг окончания официальной поддержки 12 ноября 2024 года. .NET 7 ранее поддерживался в модели изолированного рабочего процесса, но достиг окончания официальной поддержки 14 мая 2024 года.

² Процесс сборки также требует пакета SDK .NET.

³ Поддержка завершается для версии 1.x среды выполнения Функции Azure 14 сентября 2026 года. Дополнительную информацию см. в этом объявлении о поддержке. Для дальнейшей полной поддержки следует перенести приложения в версию 4.x.

⁴ Поддержка заканчивается для модели в обработке 10 ноября 2026 года. Дополнительную информацию см. в этом объявлении о поддержке. Для непрерывной поддержки следует перенести приложения в изолированную рабочую модель.

⁵ Вы не можете запускать приложения .NET 10 на Linux в плане Consumption. Для запуска в Linux следует использовать план потребления Flex. Пошаговые инструкции по миграции см. в статье "Миграция приложений плана потребления" в план потребления Flex.

Последние новости о выпусках Функции Azure, включающие удаление определенных устаревших второстепенных версий, отслеживайте в объявлениях Служба приложений Azure.

Обновление к версии .NET 8

Приложения, использующие внутрипроцессную модель, могут нацеливаться на .NET 8, выполнив действия, описанные в этом разделе. Тем не менее, если вы решите воспользоваться этой опцией, вам следует начать планирование миграции на изолированную рабочую модель заранее, в преддверии завершения поддержки модели в процессе 10 ноября 2026 года.

Многие приложения могут изменять конфигурацию приложения-функции в Azure без обновлений кода или повторного развертывания. Для запуска .NET 8 с моделью в процессе необходимо выполнить три конфигурации:

• Параметр FUNCTIONS_WORKER_RUNTIME приложения должен быть задан со значением dotnet.
• Параметр FUNCTIONS_EXTENSION_VERSION приложения должен быть задан со значением ~4.
• Параметр FUNCTIONS_INPROC_NET8_ENABLED приложения должен быть задан со значением "1".
• Чтобы ссылаться на .NET 8, необходимо обновить конфигурацию стека.

Поддержка .NET 8 по-прежнему использует версию 4.x среды выполнения Функций, и изменения в настроенной версии среды выполнения не требуются.

Чтобы обновить локальный проект, сначала убедитесь, что вы используете последние версии локальных средств. Затем убедитесь, что проект ссылается на version 4.4.0 или более поздней версии Майкрософт.NET. Sdk.Functions. Затем вы можете изменить TargetFramework на "net8.0". Необходимо также обновить local.settings.json, чтобы задать как FUNCTIONS_WORKER_RUNTIME значение "dotnet", так и FUNCTIONS_INPROC_NET8_ENABLED значение "1".

В следующем примере представлен минимальный project файл с этими изменениями:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.4.0" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

В следующем примере представлен минимальный local.settings.json файл с этими изменениями:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_INPROC_NET8_ENABLED": "1",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet"
    }
}

Если приложение использует Майкрософт.Azure.DurableTask.Netherite.AzureFunctions, убедитесь, что оно предназначено для версии 1.5.3 или более поздней. Из-за изменения поведения в .NET 8 приложения с более старыми версиями пакета вызывают неоднозначное исключение конструктора.

Возможно, вам потребуется внести изменения в приложение в зависимости от поддержки версий его других зависимостей.

Версия 4.x среды выполнения Функций предоставляет эквивалентные функциональные возможности для .NET 6 и .NET 8. Модель внутрипроцессного процесса не включает другие функции или обновления, которые интегрируются с новыми возможностями .NET 8. Например, среда выполнения не поддерживает ключи служб. Чтобы воспользоваться всеми преимуществами последних возможностей и улучшений .NET 8, необходимо перейти к изолированной рабочей модели.

Проект библиотеки классов функций

В Visual Studio шаблон проекта Функции Azure создает проект библиотеки классов C#, содержащий следующие файлы:

• host.json — сохраняет параметры конфигурации, которые влияют на все функции проекта как при локальной работе, так и в Azure.
• local.settings.json — хранит параметры приложений и строки подключения, которые используются при выполнении в локальной среде. Этот файл содержит секреты и не публикуется в вашем приложении функций на Azure. Вместо этого добавьте параметры в ваше функциональное приложение.

При построении проекта в выходном каталоге создается приблизительно такая структура папок:

<framework.version>
 | - bin
 | - MyFirstFunction
 | | - function.json
 | - MySecondFunction
 | | - function.json
 | - host.json

Этот каталог развертывается в приложении-функции в Azure. Расширения привязки, необходимые в версии 2.x среды выполнения функций, добавляются в проект как пакеты NuGet.

Внимание

Процесс сборки создает файл function.json для каждой функции. Этот function.json файл не предназначен для непосредственного редактирования. Невозможно изменить конфигурацию привязки или отключить функцию путем редактирования этого файла. Чтобы узнать, как отключить функцию, см. раздел Отключение функций.

Методы, распознаваемые как функции

В библиотеке классов функция — это метод с FunctionName атрибутом триггера, как показано в следующем примере:

public static class SimpleExample
{
    [FunctionName("QueueTrigger")]
    public static void Run(
        [QueueTrigger("myqueue-items")] string myQueueItem, 
        ILogger log)
    {
        log.LogInformation($"C# function processed: {myQueueItem}");
    }
} 

Атрибут FunctionName помечает метод как точку входа функции. Имя в проекте должно быть уникальным, начинаться с буквы и содержать только буквы, цифры, _ и -, а его длина не должна превышать 127 знаков. Шаблоны Project часто создают метод с именем Run, но имя метода может быть любым допустимым именем метода C#. В предыдущем примере показано, как используется статический метод, но функции не обязательно должны быть статическими.

Атрибут триггера указывает тип триггера и привязывает входные данные к параметру метода. Пример функции вызывается сообщением очереди, и сообщение очереди передается в метод через параметр myQueueItem.

Параметры сигнатуры метода

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

• Входные и выходные привязки, помеченные как таковые путем дополнения атрибутами.
• Параметр ILogger или TraceWriter (только для версий 1.x) для ведения журнала.
• Параметр CancellationToken для нормального завершения работы.
• Параметры связывающих выражений для получения метаданных триггера.

Порядок параметров в сигнатуре функции не имеет значения. Например, можно указать параметры триггера до или после других привязок, а параметр для средства ведения журнала — до или после параметров триггера или привязки.

Выходные привязки

Функция может иметь ноль или несколько выходных привязок, определенных с помощью выходных параметров.

В следующем примере изменяется предыдущий путем добавления привязки очереди вывода с именем myQueueItemCopy. Функция записывает содержимое сообщения, которое запускает функцию для нового сообщения в другой очереди.

public static class SimpleExampleWithOutput
{
    [FunctionName("CopyQueueMessage")]
    public static void Run(
        [QueueTrigger("myqueue-items-source")] string myQueueItem, 
        [Queue("myqueue-items-destination")] out string myQueueItemCopy,
        ILogger log)
    {
        log.LogInformation($"CopyQueueMessage function processed: {myQueueItem}");
        myQueueItemCopy = myQueueItem;
    }
}

Значения, назначенные выходным привязкам, записываются при выходе из функции. Вы можете использовать несколько выходных привязок в функции, назначив значения нескольким выходным параметрам.

В справочных статьях по привязкам (например, очередь хранилища) объясняется, какие типы параметров можно использовать с триггерами, а также с атрибутами входных или выходных привязок.

Пример примеров привязки выражений

Приведенный ниже код позволяет получить имя очереди для мониторинга из настроек приложения и время создания сообщения очереди в параметре insertionTime.

public static class BindingExpressionsExample
{
    [FunctionName("LogQueueMessage")]
    public static void Run(
        [QueueTrigger("%queueappsetting%")] string myQueueItem,
        DateTimeOffset insertionTime,
        ILogger log)
    {
        log.LogInformation($"Message content: {myQueueItem}");
        log.LogInformation($"Created at: {insertionTime}");
    }
}

Автоматически созданный файл function.json

Процесс сборки создает файл function.json в папке функции в папке сборки. Как отмечалось ранее, этот файл не предназначен для непосредственного редактирования. Невозможно изменить конфигурацию привязки или отключить функцию путем редактирования этого файла.

Назначение этого файла — предоставить сведения контроллеру масштаба для принятия решений о масштабировании плана потребления. По этой причине файл содержит только сведения о триггерах, но не о входных или выходных привязках.

Созданный файл function.json включает свойство configurationSource, которое сообщает среде выполнения использовать атрибуты .NET для привязок, а не конфигурацию function.json. Приведем пример:

{
  "generatedBy": "Microsoft.NET.Sdk.Functions-1.0.0.0",
  "configurationSource": "attributes",
  "bindings": [
    {
      "type": "queueTrigger",
      "queueName": "%input-queue-name%",
      "name": "myQueueItem"
    }
  ],
  "disabled": false,
  "scriptFile": "..\\bin\\FunctionApp1.dll",
  "entryPoint": "FunctionApp1.QueueTrigger.Run"
}

Майкрософт.NET. Sdk.Functions

Создание файла function.json выполняется пакетом NuGet Майкрософт.NET. Sdk.Functions.

В следующем примере показаны соответствующие части .csproj файлов, которые имеют разные целевые фреймворки в составе одного пакета Sdk.

v4.x

<PropertyGroup>
  <TargetFramework>net8.0</TargetFramework>
  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.5.0" />
</ItemGroup>

Внимание

Начиная с версии 4.0.6517 основных инструментов, встроенные модельные проекты должны ссылаться на версию 4.5.0 или более позднюю версиюМайкрософт.NET.Sdk.Functions. Если используется более ранняя версия, команда func start вызовет ошибку.

v1.x

<PropertyGroup>
  <TargetFramework>net48</TargetFramework>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
</ItemGroup>

К зависимостям пакетов Sdk относятся триггеры и привязки. Проект 1.x относится к триггерам и привязкам 1.x, поскольку эти триггеры и привязки предназначены для платформы .NET Framework, в то время как триггеры и привязки 4.x предназначены для .NET Core.

Пакет Sdk также зависит от пакета Newtonsoft.Json и косвенно от пакета WindowsAzure.Storage. Эти зависимости гарантируют, что проект использует версии пакетов, совместимые с версией среды выполнения Функций, для которой он предназначен. Например, Newtonsoft.Json имеет версию 11 для .NET Framework 4.6.1, но среда выполнения функций, предназначенная для платформы .NET Framework 4.6.1, совместима только с Newtonsoft.Json 9.0.1. Поэтому код функции в этом проекте также должен использовать пакет Newtonsoft.Json версии 9.0.1.

Исходный код для Майкрософт.NET.Sdk.Functions доступен в репозитории GitHub azure-functions-vs-build-sdk.

Версия локальной среды выполнения

Visual Studio использует Функции Azure Core Tools для запуска проектов Функций на локальном компьютере. Основные инструменты — это интерфейс командной строки среды выполнения Функций.

Если установить основные инструменты с помощью пакета установщика Windows (MSI) или с помощью npm, это не влияет на версию Core Tools, используемую Visual Studio. Для среды выполнения функций версии 1.x Visual Studio хранит версии Core Tools в %USERPROFILE%\AppData\Local\Azure. Functions.Cli и использует последнюю версию, хранящуюся там. Для функций 4.x основные инструменты включены в расширение Функции Azure и Web Jobs Tools. В функциях 1.x вы можете увидеть, какая версия используется в выводе консоли при запуске проекта функций.

[3/1/2018 9:59:53 AM] Starting Host (HostId=contoso2-1518597420, Version=2.0.11353.0, ProcessId=22020, Debug=False, Attempt=0, FunctionsExtensionVersion=)

ReadyToRun

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

ReadyToRun доступен в .NET 6 и более поздних версиях и требует version 4.0 среды выполнения Функции Azure.

Чтобы скомпилировать проект как ReadyToRun, обновите файл проекта, добавив элементы <PublishReadyToRun> и <RuntimeIdentifier>. В следующем примере показана конфигурация публикации в 32-разрядном приложении-функции Windows.

<PropertyGroup>
  <TargetFramework>net8.0</TargetFramework>
  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
  <PublishReadyToRun>true</PublishReadyToRun>
  <RuntimeIdentifier>win-x86</RuntimeIdentifier>
</PropertyGroup>

Внимание

Начиная с .NET 6 добавлена поддержка компиляции Composite ReadyToRun. Ознакомьтесь с ограничениями платформы и архитектуры ReadyToRun Cross.

Кроме того, можно создать приложение с помощью ReadyToRun из командной строки. Дополнительные сведения см. в параметре -p:PublishReadyToRun=true в dotnet publish.

Поддерживаемые типы для привязок

Каждая привязка поддерживает свои собственные типы. Например, атрибут триггера большого двоичного объекта можно применить к строковому параметру, параметру POCO, параметру CloudBlockBlob, или к любому из нескольких других поддерживаемых типов. В справочной статье о привязках для BLOB приводится список всех поддерживаемых типов параметров. Дополнительные сведения см. в статье о триггерах и привязках и в справочной документации по каждому типу привязки.

Совет

Если вы планируете использовать привязки HTTP или веб-перехватчика, спланируйте работу так, чтобы избежать нехватки портов, которая может возникнуть в результате неправильной установки HttpClient. Дополнительные сведения см. в разделе Как управлять подключениями в Функции Azure.

Привязка к возвращаемому значению метода

Возвращаемое значение метода можно использовать для привязки выходных данных. Для этого примените атрибут к возвращаемому значению метода. Примеры см. в статье о триггерах и привязках.

Используйте возвращаемое значение только в том случае, если успешное выполнение функции гарантированно возвращает значение, которое затем передаётся в выходную привязку. В противном случае используйте ICollector или IAsyncCollector, как указано в следующем разделе.

Написание нескольких значений выходных данных

Для записи нескольких значений в выходную привязку, или если успешный вызов функции не приведет к необходимости передавать что-либо в выходную привязку, используйте типы ICollector или IAsyncCollector. Эти типы представляют собой доступные только для записи коллекции, записываемые в выходную привязку по завершении метода.

В этом примере несколько сообщений записываются в одну и ту же очередь с помощью ICollector.

public static class ICollectorExample
{
    [FunctionName("CopyQueueMessageICollector")]
    public static void Run(
        [QueueTrigger("myqueue-items-source-3")] string myQueueItem,
        [Queue("myqueue-items-destination")] ICollector<string> myDestinationQueue,
        ILogger log)
    {
        log.LogInformation($"C# function processed: {myQueueItem}");
        myDestinationQueue.Add($"Copy 1: {myQueueItem}");
        myDestinationQueue.Add($"Copy 2: {myQueueItem}");
    }
}

Асинхрон

Чтобы сделать функцию асинхронной, используйте ключевое слово async и верните объект Task.

public static class AsyncExample
{
    [FunctionName("BlobCopy")]
    public static async Task RunAsync(
        [BlobTrigger("sample-images/{blobName}")] Stream blobInput,
        [Blob("sample-images-copies/{blobName}", FileAccess.Write)] Stream blobOutput,
        CancellationToken token,
        ILogger log)
    {
        log.LogInformation($"BlobCopy function processed.");
        await blobInput.CopyToAsync(blobOutput, 4096, token);
    }
}

Вы не можете использовать параметры out в асинхронных функциях. Вместо этих параметров для выходных привязок используйте возвращаемое значение функции или объект сборщика.

Токены отмены

Функция может принимать параметр CancellationToken, который позволяет операционной системе передавать в ваш код сведения о том, что выполнение функции будет завершено. Это уведомление можно использовать для предотвращения ситуации, когда выполнение функции завершается неожиданно, оставляя данные в несогласованном состоянии.

Рассмотрим ситуацию, когда у вас есть функция, которая обрабатывает сообщения пакетами. Следующая функция, активировавшаяся Служебная шина Azure, обрабатывает массив объектов ServiceBusReceivedMessage, который представляет пакет входящих сообщений для обработки определенным вызовом функции:

using Azure.Messaging.ServiceBus;
using System.Threading;

namespace ServiceBusCancellationToken
{
    public static class servicebus
    {
        [FunctionName("servicebus")]
        public static void Run([ServiceBusTrigger("csharpguitar", Connection = "SB_CONN")]
               ServiceBusReceivedMessage[] messages, CancellationToken cancellationToken, ILogger log)
        {
            try
            { 
                foreach (var message in messages)
                {
                    if (cancellationToken.IsCancellationRequested)
                    {
                        log.LogInformation("A cancellation token was received. Taking precautionary actions.");
                        //Take precautions like noting how far along you are with processing the batch
                        log.LogInformation("Precautionary activities --complete--.");
                        break;
                    }
                    else
                    {
                        //business logic as usual
                        log.LogInformation($"Message: {message} was processed.");
                    }
                }
            }
            catch (Exception ex)
            {
                log.LogInformation($"Something unexpected happened: {ex.Message}");
            }
        }
    }
}

Ведение журнала

В коде функции вы можете записывать выходные данные в журналы, которые отображаются в виде трассировок в Application Insights. Рекомендуемый способ записи в журналы — включить параметр типа ILogger, который обычно называется log. Версия 1.x среды выполнения Azure Functions использует TraceWriter, который также выполняет запись в Application Insights, но не поддерживает структурированное логирование. Не следует использовать Console.Write для записи журналов, так как эти данные не фиксируются Application Insights.

ILogger

Включите в определение функции параметр ILogger, который поддерживает структурированное ведение журнала.

Объект ILogger позволяет вызывать методы расширения на Log<level>ILogger для создания журналов. Следующий код записывает журналы Information с категорией Function.<YOUR_FUNCTION_NAME>.User..

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, ILogger logger)
{
    logger.LogInformation("Request for item with key={itemKey}.", id);

Дополнительные сведения о реализации ILogger см. в разделе Сбор данных телеметрии. Категории с префиксом Function предполагают использование ILogger экземпляра. Если вы вместо этого решите использовать ILogger<T>, имя категории может быть основано на T.

Структурированное логирование

Использование параметров в сообщении журнала определяется порядком заполнителей, а не их именами. Предположим, что у вас есть следующий код:

string partitionKey = "partitionKey";
string rowKey = "rowKey";
logger.LogInformation("partitionKey={partitionKey}, rowKey={rowKey}", partitionKey, rowKey);

Если вы примените эту же строку сообщения с обратным порядком параметров, в тексте сообщения значения окажутся на неправильных местах.

Такой метод обработки заполнителей позволяет выполнять структурированное ведение журналов. Application Insights сохраняет пары параметров "имя-значение" и строку сообщения. Благодаря этому все аргументы сообщения становятся полями, по которым можно выполнять запросы.

Если ваш вызов метода логирования выглядит как в предыдущем примере, вы можете запросить поле customDimensions.prop__rowKey. При этом добавляется префикс prop__, чтобы не возникало конфликтов между полями, которые добавляет среда выполнения и которые добавляет код вашей функции.

Исходную строку сообщения можно получить, указав в запросе поле customDimensions.prop__{OriginalFormat}.

Ниже приведен пример JSON-представления для данных customDimensions.

{
  "customDimensions": {
    "prop__{OriginalFormat}":"C# Queue trigger function processed: {message}",
    "Category":"Function",
    "LogLevel":"Information",
    "prop__message":"c9519cbf-b1e6-4b9b-bf24-cb7d10b1bb89"
  }
}

Ведение журнала пользовательской телеметрии

Внимание

OpenTelemetry не поддерживается в приложениях функций C# внутри процесса. Для изолированной рабочей модели используйте экспортер OpenTelemetry , который рекомендуется использовать для пользовательской телеметрии. Классический пакет SDK Application Insights, показанный в этом разделе, является устаревшим и не будет получать новые обновления компонентов.

Существует версия пакета SDK Application Insights, специфичная для Функций, которую можно использовать для отправки пользовательских данных телеметрии из функций в Application Insights: Майкрософт.Azure.WebJobs.Logging.ApplicationInsights. Для установки этого пакета используйте следующую команду из командной строки:

dotnet add package Microsoft.Azure.WebJobs.Logging.ApplicationInsights --version <VERSION>

PowerShell

Install-Package Microsoft.Azure.WebJobs.Logging.ApplicationInsights -Version <VERSION>

В этой команде замените <VERSION> на версию этого пакета, которая поддерживает установленную версию Майкрософт.Azure.WebJobs.

В следующем примере C# используется настраиваемый интерфейс API телеметрии. Пример — для библиотеки классов .NET, но код Application Insights совпадает со скриптом C#.

v4.x

Среда выполнения версий 2.x и более поздних использует новые функции Application Insights для автоматической корреляции данных телеметрии с текущей операцией. Нет необходимости вручную задавать для операции поля Id, ParentId или Name.

using System;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;

using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
using System.Linq;

namespace functionapp0915
{
    public class HttpTrigger2
    {
        private readonly TelemetryClient telemetryClient;

        /// Using dependency injection will guarantee that you use the same configuration for telemetry collected automatically and manually.
        public HttpTrigger2(TelemetryConfiguration telemetryConfiguration)
        {
            this.telemetryClient = new TelemetryClient(telemetryConfiguration);
        }

        [FunctionName("HttpTrigger2")]
        public Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = null)]
            HttpRequest req, ExecutionContext context, ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");
            DateTime start = DateTime.UtcNow;

            // Parse query parameter
            string name = req.Query
                .FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
                .Value;

            // Write an event to the customEvents table.
            var evt = new EventTelemetry("Function called");
            evt.Context.User.Id = name;
            this.telemetryClient.TrackEvent(evt);

            // Generate a custom metric, in this case let's use ContentLength.
            this.telemetryClient.GetMetric("contentLength").TrackValue(req.ContentLength);

            // Log a custom dependency in the dependencies table.
            var dependency = new DependencyTelemetry
            {
                Name = "GET api/planets/1/",
                Target = "swapi.co",
                Data = "https://swapi.co/api/planets/1/",
                Timestamp = start,
                Duration = DateTime.UtcNow - start,
                Success = true
            };
            dependency.Context.User.Id = name;
            this.telemetryClient.TrackDependency(dependency);

            return Task.FromResult<IActionResult>(new OkResult());
        }
    }
}

В этом примере пользовательские метрики агрегируются хостом перед отправкой в таблицу customMetrics. Для получения дополнительной информации см. документацию по GetMetric в Application Insights.

В случае локального запуска необходимо добавить параметр APPINSIGHTS_INSTRUMENTATIONKEY с ключом Application Insights в файл local.settings.json.

v1.x

using System;
using System.Net;
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.Azure.WebJobs;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;
using System.Linq;

namespace functionapp0915
{
    public static class HttpTrigger2
    {
        private static string key = TelemetryConfiguration.Active.InstrumentationKey = 
            System.Environment.GetEnvironmentVariable(
                "APPINSIGHTS_INSTRUMENTATIONKEY", EnvironmentVariableTarget.Process);

        private static TelemetryClient telemetryClient = 
            new TelemetryClient() { InstrumentationKey = key };

        [FunctionName("HttpTrigger2")]
        public static async Task<HttpResponseMessage> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)]
            HttpRequestMessage req, ExecutionContext context, ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");
            DateTime start = DateTime.UtcNow;

            // Parse query parameter
            string name = req.GetQueryNameValuePairs()
                .FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
                .Value;

            // Get request body
            dynamic data = await req.Content.ReadAsAsync<object>();

            // Set name to query string or body data
            name = name ?? data?.name;
         
            // Track an Event
            var evt = new EventTelemetry("Function called");
            UpdateTelemetryContext(evt.Context, context, name);
            telemetryClient.TrackEvent(evt);
            
            // Track a Metric
            var metric = new MetricTelemetry("Test Metric", DateTime.Now.Millisecond);
            UpdateTelemetryContext(metric.Context, context, name);
            telemetryClient.TrackMetric(metric);
            
            // Track a Dependency
            var dependency = new DependencyTelemetry
            {
                Name = "GET api/planets/1/",
                Target = "swapi.co",
                Data = "https://swapi.co/api/planets/1/",
                Timestamp = start,
                Duration = DateTime.UtcNow - start,
                Success = true
            };
            UpdateTelemetryContext(dependency.Context, context, name);
            telemetryClient.TrackDependency(dependency);
        }
        
        // Correlate all telemetry with the current Function invocation
        private static void UpdateTelemetryContext(TelemetryContext context, ExecutionContext functionContext, string userName)
        {
            context.Operation.Id = functionContext.InvocationId.ToString();
            context.Operation.ParentId = functionContext.InvocationId.ToString();
            context.Operation.Name = functionContext.FunctionName;
            context.User.Id = userName;
        }
    }    
}

Не вызывайте TrackRequest или StartOperation<RequestTelemetry>, потому что вы видите дублирующиеся запросы на выполнение функции. Среда выполнения Функций автоматически отслеживает запросы.

Не указывайте telemetryClient.Context.Operation.Id. Этот глобальный параметр может вызвать неправильную корреляцию при одновременном выполнении нескольких функций. Вместо этого создайте экземпляр телеметрии (DependencyTelemetry, EventTelemetry) и измените его свойство Context. Затем передайте экземпляр телеметрии в соответствующий метод Track в TelemetryClient (TrackDependency(), TrackEvent(), TrackMetric()). Этот метод гарантирует правильность телеметрических данных о корреляции для текущего вызова функции.

Функции тестирования

В следующих статьях показано, как локально запустить функцию библиотеки классов C# внутри процесса для тестирования:

• Visual Studio
• Visual Studio Code
• Командная строка

Переменные среды

Чтобы получить значение переменной среды или значение параметра приложения, используйте System.Environment.GetEnvironmentVariable, как показано в следующем примере кода.

public static class EnvironmentVariablesExample
{
    [FunctionName("GetEnvironmentVariables")]
    public static void Run([TimerTrigger("0 */5 * * * *")]TimerInfo myTimer, ILogger log)
    {
        log.LogInformation($"C# Timer trigger function executed at: {DateTime.Now}");
        log.LogInformation(GetEnvironmentVariable("AzureWebJobsStorage"));
        log.LogInformation(GetEnvironmentVariable("WEBSITE_SITE_NAME"));
    }

    private static string GetEnvironmentVariable(string name)
    {
        return name + ": " +
            System.Environment.GetEnvironmentVariable(name, EnvironmentVariableTarget.Process);
    }
}

Параметры приложения можно считывать из переменных среды как при локальной разработке, так и при запуске в Azure. При локальной разработке параметры приложения поступают из коллекции Values файла local.settings.json. В обеих средах, локальной и Azure, GetEnvironmentVariable("<app setting name>") извлекает значение именованной настройки приложения. Например, при локальном запуске будет возвращено "Имя_сайта", если файл local.settings.json содержит { "Values": { "WEBSITE_SITE_NAME": "My Site Name" } }.

Свойство System.Configuration.ConfigurationManager.AppSettings — альтернативный API-интерфейс для получения значения параметра приложения, но рекомендуется использовать GetEnvironmentVariable, как показано ниже.

Привязка во время выполнения

В C# и других языках .NET можно использовать императивный шаблон привязки , в отличие от декларативных привязок в атрибутах. Императивную привязку удобно использовать, когда параметры привязки должны вычисляться не при проектировании, а во время выполнения. С использованием такого шаблона можно моментально выполнить привязку к поддерживаемым входным и выходным привязкам в коде функции.

Определите принудительную привязку следующим образом.

• Не добавляйте атрибут в сигнатуру функции для нужных императивных привязок.

• Передайте входной параметр Binder binder или IBinder binder.

• Используйте следующий шаблон C# для привязки данных,

  using (var output = await binder.BindAsync<T>(new BindingTypeAttribute(...)))
  {
      ...
  }
  

  BindingTypeAttribute — это атрибут .NET, определяющий привязку, а T — входной или выходной тип, поддерживаемый этим типом привязки. T не может быть типом out параметра (например out JObject, ). Например, выходная привязка для мобильных приложений поддерживает шесть типов выходных данных, но вы можете использовать только или < в случае императивной привязки.

Пример с одним атрибутом

В следующем примере кода создается выходная привязка для объекта Blob хранилища с путем к Blob-объекту, заданным во время выполнения, а затем в этот объект записывается строка.

public static class IBinderExample
{
    [FunctionName("CreateBlobUsingBinder")]
    public static void Run(
        [QueueTrigger("myqueue-items-source-4")] string myQueueItem,
        IBinder binder,
        ILogger log)
    {
        log.LogInformation($"CreateBlobUsingBinder function processed: {myQueueItem}");
        using (var writer = binder.Bind<TextWriter>(new BlobAttribute(
                    $"samples-output/{myQueueItem}", FileAccess.Write)))
        {
            writer.Write("Hello World!");
        };
    }
}

BlobAttribute определяет входную или выходную привязку для Storage blob, а TextWriter является поддерживаемым типом выходной привязки.

Пример с несколькими атрибутами

В предыдущем примере извлекается настройка приложения для строки подключения к основной учетной записи хранения приложения-функции (которая равна AzureWebJobsStorage). Можно указать настраиваемый параметр приложения, используемый для учетной записи хранения, добавив StorageAccountAttribute и передав массив атрибутов в BindAsync<T>(). Используйте параметр Binder, а не IBinder. Например:

public static class IBinderExampleMultipleAttributes
{
    [FunctionName("CreateBlobInDifferentStorageAccount")]
    public async static Task RunAsync(
            [QueueTrigger("myqueue-items-source-binder2")] string myQueueItem,
            Binder binder,
            ILogger log)
    {
        log.LogInformation($"CreateBlobInDifferentStorageAccount function processed: {myQueueItem}");
        var attributes = new Attribute[]
        {
        new BlobAttribute($"samples-output/{myQueueItem}", FileAccess.Write),
        new StorageAccountAttribute("MyStorageAccount")
        };
        using (var writer = await binder.BindAsync<TextWriter>(attributes))
        {
            await writer.WriteAsync("Hello World!!");
        }
    }
}

Триггеры и привязки

В этой таблице показаны привязки, поддерживаемые в основных версиях среды выполнения Функции Azure:

Тип	4.x1	1.x2	Триггер	Входные данные	Выходные данные
Хранилище BLOB-объектов	✔	✔	✔	✔	✔
Azure Cosmos DB	✔	✔	✔	✔	✔
Обозреватель данных Azure	✔			✔	✔
Azure SQL	✔		✔	✔	✔
Dapr4	✔		✔	✔	✔
Сетка событий	✔	✔	✔		✔
Центры событий	✔	✔	✔		✔
HTTP и веб-перехватчики	✔	✔	✔		✔
Центр IoT	✔	✔	✔
Kafka3	✔		✔		✔
Мобильные приложения		✔		✔	✔
Протокол контекста модели	✔		✔
Центры уведомлений		✔		✔
Хранилище очередей	✔	✔	✔		✔
Редис	✔		✔	✔	✔
RabbitMQ3	✔		✔		✔
SendGrid	✔	✔			✔
служебная шина	✔	✔	✔		✔
Служба Azure SignalR	✔		✔	✔	✔
Хранилище таблиц	✔	✔		✔	✔
Таймер	✔	✔	✔
Twilio	✔	✔			✔

1. Зарегистрируйте все привязки, кроме HTTP и таймера. См. Регистрация расширений привязок Функции Azure. Этот шаг не требуется при использовании среды выполнения Функций версии 1.x.
2. Support заканчивается для версии 1.x среды выполнения Функции Azure 14 сентября 2026. Перенос приложений в версию 4.x для полной поддержки.
3. Триггеры не поддерживаются в тарифном плане Consumption. Для этого типа привязки требуются триггеры, управляемые средой выполнения.
4. Этот тип привязки поддерживается только в Kubernetes, Azure IoT Edge и других автономных режимах.

Следующие шаги

Дополнительные сведения о триггерах и привязках

Узнайте больше о лучших практиках для Функции Azure