Руководство по запуску Azure Functions C# в изолированной рабочей модели

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

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

Сведения о развертывании проекта изолированной рабочей модели в Azure см. в статье Развертывание в Azure Functions.

Преимущества изолированной рабочей модели

Функции библиотеки классов .NET можно запускать в двух режимах: в том же процессе, что и среда выполнения хост-функций (внутри процесса), или в изолированном рабочем процессе. Если функции .NET выполняются в изолированном рабочем процессе, вы можете воспользоваться следующими преимуществами:

• Меньше конфликтов: поскольку функции выполняются в отдельном процессе, сборки, используемые в приложении, не конфликтуют с разными версиями одинаковых сборок, используемых узлом.
• Полный контроль над процессом: вы управляете запуском приложения, что означает, что вы можете управлять конфигурациями, используемыми и запущенным ПО промежуточного слоя.
• Стандартное внедрение зависимостей: Так как у вас есть полный контроль над процессом, можно использовать текущие поведения .NET для внедрения зависимостей и включения промежуточного слоя в ваше функциональное приложение.
• Гибкость версий .NET: Выполнение функций вне процесса хоста позволяет им работать на версиях .NET, которые не поддерживаются нативно средой выполнения Functions, включая платформу .NET Framework.

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

Полное сравнение двух режимов см. в разделе Различия между режимами внутрипроцессного и изолированного рабочего процесса .NET Azure Functions.

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

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

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

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

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

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

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

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

Для получения последних новостей о выпусках Azure Functions, включая удаление некоторых более ранних минорных версий, отслеживайте объявления Azure App Service.

Структура проекта

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

• Файл проекта C# (.csproj), определяющий проект и зависимости.
• Файл Program.cs, который служит в качестве точки входа в приложение.
• Все файлы кода, определяющие функции.
• host.json файл, определяющий конфигурацию, общей для функций в вашем проекте.
• local.settings.json файл, определяющий переменные среды, используемые project при локальном запуске на компьютере.

Полные примеры см. в примере .NET 8 project и .NET Framework 4.8 project.

Ссылки на пакеты

Проект .NET для Azure Functions, в котором используется изолированная модель рабочего процесса, использует уникальный набор пакетов для основных возможностей и расширений привязки.

Основные пакеты

Чтобы запустить функции .NET в изолированном рабочем процессе, вам потребуется следующее:

• Microsoft. Azure. Functions.Worker
• Microsoft. Azure. Functions.Worker.Sdk

Минимальные версии этих пакетов зависят от целевой .NET версии:

Версия 2.x

Версии 2.x основных пакетов изменяют поддерживаемые платформы и поддерживают новые API-интерфейсы .NET из этих более поздних версий. При обновлении до версий 2.x обратите внимание на следующие изменения:

• Начиная с версии 2.0.0 Microsoft. Azure. Functions.Worker.Sdk:
  • Пакет SDK включает конфигурации по умолчанию для сборок контейнеров SDK.
  • Пакет SDK включает поддержку dotnet run при установке Azure Functions Core Tools. В Windows установите основные средства с помощью механизма, отличного от NPM.
• Начиная с версии 2.0.0 Microsoft. Azure. Functions.Worker:
  • Эта версия добавляет поддержку IHostApplicationBuilder. Некоторые примеры в этом руководстве включают вкладки для отображения альтернативных вариантов с помощью IHostApplicationBuilder. В этих примерах требуются версии 2.x.
  • Проверка области поставщика услуг включается по умолчанию, если выполняется в среде разработки. Это поведение соответствует ASP.NET Core.
  • Параметр EnableUserCodeException включен по умолчанию. Теперь свойство помечается как устаревшее.
  • Параметр IncludeEmptyEntriesInMessagePayload включен по умолчанию. Если этот параметр включен, полезные данные, которые триггерируются и представляют собой коллекции, всегда включают пустые записи. Например, если сообщение отправляется без содержимого, пустая запись остается в string[] для данных триггера. Включение пустых записей упрощает перекрестную ссылку с массивами метаданных, на которые также может ссылаться функция. Это поведение можно отключить, установив значение IncludeEmptyEntriesInMessagePayloadfalse в WorkerOptions конфигурации службы.
  • Класс ILoggerExtensions переименован на FunctionsLoggerExtensions. Переименование предотвращает неоднозначную ошибку вызова при использовании LogMetric() в экземпляре ILogger .
  • Для приложений, использующих HttpResponseData, метод WriteAsJsonAsync() больше не задает код состояния 200 OK. В версии 1.x это поведение отменяло действие других заданных вами кодов ошибок.
• В версиях 2.x прекращена поддержка .NET 5 TFM.

Пакеты расширений

Так как .NET изолированные функции рабочего процесса используют различные типы привязки, они требуют уникального набора пакетов расширений привязки.

Эти пакеты расширений находятся в разделе Microsoft. Azure. Functions.Worker.Extensions.

Запуск и настройка

При использовании изолированной рабочей модели вы имеете доступ к запуску приложения-функции, который обычно находится в Program.cs. Вам нужно самостоятельно создавать и запускать собственный хост-экземпляр. Таким образом, вы также можете напрямую получить доступ к потоку настройки вашего приложения. Благодаря изолированному рабочему процессу функций .NET можно гораздо проще добавлять конфигурации, внедрять зависимости и запускать собственное ПО промежуточного слоя.

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Logging.Services.Configure<LoggerFilterOptions>(options =>
    {
        // The Application Insights SDK adds a default logging filter that instructs ILogger to capture only Warning and more severe logs. Application Insights requires an explicit override.
        // Log levels can also be configured using appsettings.json. For more information, see https://learn.microsoft.com/azure/azure-monitor/app/worker-service#ilogger-logs
        LoggerFilterRule? defaultRule = options.Rules.FirstOrDefault(rule => rule.ProviderName
            == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
        if (defaultRule is not null)
        {
            options.Rules.Remove(defaultRule);
        }
    });

var host = builder.Build();

await host.RunAsync();

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(s =>
    {
        s.AddApplicationInsightsTelemetryWorkerService();
        s.ConfigureFunctionsApplicationInsights();
        s.AddSingleton<IHttpResponderService, DefaultHttpResponderService>();
        s.Configure<LoggerFilterOptions>(options =>
        {
            // The Application Insights SDK adds a default logging filter that instructs ILogger to capture only Warning and more severe logs. Application Insights requires an explicit override.
            // Log levels can also be configured using appsettings.json. For more information, see https://learn.microsoft.com/en-us/azure/azure-monitor/app/worker-service#ilogger-logs
            LoggerFilterRule? toRemove = options.Rules.FirstOrDefault(rule => rule.ProviderName
                == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");

            if (toRemove is not null)
            {
                options.Rules.Remove(toRemove);
            }
        });
    })
    .Build();

Настройка

Тип построителя, который вы используете, определяет, как настроить приложение.

.ConfigureFunctionsWorkerDefaults()

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

Внедрение зависимостей

Изолированная рабочая модель использует стандартные механизмы .NET для внедрения служб.

builder.Services.AddSingleton<IHttpResponderService, DefaultHttpResponderService>();

.ConfigureServices(services =>
{
    services.AddSingleton<IHttpResponderService, DefaultHttpResponderService>();
})

Для этого кода требуется using Microsoft.Extensions.DependencyInjection;. Дополнительные сведения см. в статье Внедрение зависимостей в ASP.NET Core.

Регистрация клиентов Azure

Используйте внедрение зависимостей для взаимодействия с другими службами Azure. Вы можете внедрить клиентов из пакета SDK Azure для .NET с помощью пакета Microsoft.Extensions.Azure. После установки пакета зарегистрируйте клиентов, вызвав AddAzureClients() в коллекции служб в Program.cs. В следующем примере настраивается клиент named для больших двоичных объектов Azure:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.Azure;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddAzureClients(clientBuilder =>
        {
            clientBuilder.AddBlobServiceClient(builder.Configuration.GetSection("MyStorageConnection"))
                .WithName("copierOutputBlob");
        });

builder.Build().Run();

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Azure;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices((hostContext, services) =>
    {
        services.AddAzureClients(clientBuilder =>
        {
            clientBuilder.AddBlobServiceClient(hostContext.Configuration.GetSection("MyStorageConnection"))
                .WithName("copierOutputBlob");
        });
    })
    .Build();

host.Run();

В следующем примере показано, как использовать эту регистрацию и типы SDK для копирования содержимого BLOB-объектов в виде потока из одного контейнера в другой с помощью внедренного клиента:

using Microsoft.Extensions.Azure;
using Microsoft.Extensions.Logging;

namespace MyFunctionApp
{
    public class BlobCopier
    {
        private readonly ILogger<BlobCopier> _logger;
        private readonly BlobContainerClient _copyContainerClient;

        public BlobCopier(ILogger<BlobCopier> logger, IAzureClientFactory<BlobServiceClient> blobClientFactory)
        {
            _logger = logger;
            _copyContainerClient = blobClientFactory.CreateClient("copierOutputBlob").GetBlobContainerClient("samples-workitems-copy");
            _copyContainerClient.CreateIfNotExists();
        }

        [Function("BlobCopier")]
        public async Task Run([BlobTrigger("samples-workitems/{name}", Connection = "MyStorageConnection")] Stream myBlob, string name)
        {
            await _copyContainerClient.UploadBlobAsync(name, myBlob);
            _logger.LogInformation($"Blob {name} copied!");
        }

    }
}

В этом примере ILogger<T> тоже получен через внедрение зависимостей, поэтому регистрируется автоматически. Дополнительные сведения о параметрах конфигурации для ведения журнала см. в разделе "Ведение журнала".

Промежуточное ПО

Изолированная рабочая модель также поддерживает регистрацию ПО промежуточного слоя, опять же используя модель, аналогичную той, что существует в ASP.NET. Эта модель позволяет внедрить логику в конвейер вызова, а также до и после выполнения функций.

Метод расширения ConfigureFunctionsWorkerDefaults имеет перегрузку, которая позволяет зарегистрировать собственное промежуточное ПО, как показано в следующем примере.

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

// Register our custom middlewares with the worker
builder
    .UseMiddleware<ExceptionHandlingMiddleware>()
    .UseMiddleware<MyCustomMiddleware>()
    .UseWhen<StampHttpHeaderMiddleware>((context) =>
    {
        // We want to use this middleware only for http trigger invocations.
        return context.FunctionDefinition.InputBindings.Values
                        .First(a => a.Type.EndsWith("Trigger")).Type == "httpTrigger";
    });

builder.Build().Run();

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults(workerApplication =>
    {
        // Register our custom middlewares with the worker

        workerApplication.UseMiddleware<ExceptionHandlingMiddleware>();

        workerApplication.UseMiddleware<MyCustomMiddleware>();

        workerApplication.UseWhen<StampHttpHeaderMiddleware>((context) =>
        {
            // We want to use this middleware only for http trigger invocations.
            return context.FunctionDefinition.InputBindings.Values
                          .First(a => a.Type.EndsWith("Trigger")).Type == "httpTrigger";
        });
    })
    .Build();

Метод UseWhen расширения регистрирует ПО промежуточного слоя, которое выполняется условно. Необходимо передать предикат, возвращающий логическое значение этому методу. Промежуточное программное обеспечение участвует в конвейере обработки вызовов, когда предикат возвращает true.

Следующие методы расширения в FunctionContext упрощают работу с ПО промежуточного слоя в изолированной модели.

В этом примере показана реализация ПО промежуточного слоя, которая считывает HttpRequestData экземпляр и обновляет HttpResponseData экземпляр во время выполнения функции:

internal sealed class StampHttpHeaderMiddleware : IFunctionsWorkerMiddleware
{
    public async Task Invoke(FunctionContext context, FunctionExecutionDelegate next)
    {
        var requestData = await context.GetHttpRequestDataAsync();

        string correlationId;
        if (requestData!.Headers.TryGetValues("x-correlationId", out var values))
        {
            correlationId = values.First();
        }
        else
        {
            correlationId = Guid.NewGuid().ToString();
        }

        await next(context);

        context.GetHttpResponseData()?.Headers.Add("x-correlationId", correlationId);
    }
}

Это ПО промежуточного слоя проверяет наличие определенного заголовка запроса (x-correlationId). При наличии заголовка промежуточный слой использует значение заголовка для добавления в заголовок ответа. В противном случае он создает новое значение GUID и использует это значение для метки заголовка ответа.

Более полный пример использования пользовательской middleware в вашем приложении-функции см. в справочном примере по пользовательской middleware.

Настройка сериализации JSON

Модель изолированного работника по умолчанию использует System.Text.Json. Вы можете настроить поведение сериализатора, настроив службы в составе Program.cs файла. В этом разделе рассматривается сериализация общего назначения и не затрагивает сериализацию JSON триггера HTTP с интеграцией ASP.NET Core, которую необходимо настроить отдельно.

using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Services.Configure<JsonSerializerOptions>(jsonSerializerOptions =>
    {
        jsonSerializerOptions.PropertyNamingPolicy = JsonNamingPolicy.CamelCase;
        jsonSerializerOptions.DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull;
        jsonSerializerOptions.ReferenceHandler = ReferenceHandler.Preserve;

        // override the default value
        jsonSerializerOptions.PropertyNameCaseInsensitive = false;
    });

builder.Build().Run();

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication((IFunctionsWorkerApplicationBuilder builder) =>
    {
        builder.Services.Configure<JsonSerializerOptions>(jsonSerializerOptions =>
        {
            jsonSerializerOptions.PropertyNamingPolicy = JsonNamingPolicy.CamelCase;
            jsonSerializerOptions.DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull;
            jsonSerializerOptions.ReferenceHandler = ReferenceHandler.Preserve;

            // override the default value
            jsonSerializerOptions.PropertyNameCaseInsensitive = false;
        });
    })
    .Build();

host.Run();

Чтобы использовать JSON.NET (Newtonsoft.Json) для сериализации, установите пакет Microsoft.Azure.Core.NewtonsoftJson. Затем в регистрации службы переназначьте Serializer свойство в WorkerOptions конфигурации. В следующем примере показана эта конфигурация с помощью ConfigureFunctionsWebApplication, но она также работает для ConfigureFunctionsWorkerDefaults:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Services.Configure<WorkerOptions>(workerOptions =>
    {
        var settings = NewtonsoftJsonObjectSerializer.CreateJsonSerializerSettings();
        settings.ContractResolver = new CamelCasePropertyNamesContractResolver();
        settings.NullValueHandling = NullValueHandling.Ignore;

        workerOptions.Serializer = new NewtonsoftJsonObjectSerializer(settings);
    });

builder.Build().Run();

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication((IFunctionsWorkerApplicationBuilder builder) =>
    {
        builder.Services.Configure<WorkerOptions>(workerOptions =>
        {
            var settings = NewtonsoftJsonObjectSerializer.CreateJsonSerializerSettings();
            settings.ContractResolver = new CamelCasePropertyNamesContractResolver();
            settings.NullValueHandling = NullValueHandling.Ignore;

            workerOptions.Serializer = new NewtonsoftJsonObjectSerializer(settings);
        });
    })
    .Build();

host.Run();

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

Метод функции — это открытый метод общедоступного класса с атрибутом Function , примененным к методу, и атрибут триггера, примененный к входным параметру, как показано в следующем примере:

[Function(nameof(QueueInputOutputFunction))]
[QueueOutput("output-queue")]
public string[] QueueInputOutputFunction([QueueTrigger("input-queue")] Album myQueueItem, FunctionContext context)

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

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

Параметры функции

Ниже приведены некоторые параметры, которые можно включить в сигнатуру метода функции:

• Привязки, которые обозначены как таковые, путем применения параметров в качестве атрибутов. Функция должна содержать ровно один параметр триггера.
• Объект контекста выполнения, предоставляющий сведения о текущем вызове.
• Маркер отмены, используемый для корректного завершения работы.

Контекст выполнения

В изолированной рабочей модели рабочий процесс передает объект FunctionContext в методы функции. Этот объект позволяет получить экземпляр ILogger для записи в журналы путем вызова метода GetLogger и предоставления строки categoryName. Этот контекст можно использовать для получения ILogger без необходимости внедрения зависимостей. Более подробную информацию см. в разделе Ведение журналов.

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

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

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

[Function(nameof(ThrowOnCancellation))]
public async Task ThrowOnCancellation(
    [EventHubTrigger("sample-workitem-1", Connection = "EventHubConnection")] string[] messages,
    FunctionContext context,
    CancellationToken cancellationToken)
{
    _logger.LogInformation("C# EventHub {functionName} trigger function processing a request.", nameof(ThrowOnCancellation));

    foreach (var message in messages)
    {
        cancellationToken.ThrowIfCancellationRequested();
        await Task.Delay(6000); // task delay to simulate message processing
        _logger.LogInformation("Message '{msg}' was processed.", message);
    }
}

В следующем примере выполняются действия очистки при получении запроса на отмену:

[Function(nameof(HandleCancellationCleanup))]
public async Task HandleCancellationCleanup(
    [EventHubTrigger("sample-workitem-2", Connection = "EventHubConnection")] string[] messages,
    FunctionContext context,
    CancellationToken cancellationToken)
{
    _logger.LogInformation("C# EventHub {functionName} trigger function processing a request.", nameof(HandleCancellationCleanup));

    foreach (var message in messages)
    {
        if (cancellationToken.IsCancellationRequested)
        {
            _logger.LogInformation("A cancellation token was received, taking precautionary actions.");
            // Take precautions like noting how far along you are with processing the batch
            _logger.LogInformation("Precautionary activities complete.");
            break;
        }

        await Task.Delay(6000); // task delay to simulate message processing
        _logger.LogInformation("Message '{msg}' was processed.", message);
    }
}

Сценарии, которые приводят к отмене

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

• Отключение клиента: клиент, вызывающий функцию, отключается. Эта причина наиболее вероятна для HTTP-триггеров.
• Перезапуск приложения-функции: вы или платформа перезапускаете (или останавливаете) приложение-функцию примерно в то же время, когда запрашивается вызов. Перезапуск может произойти из-за перемещения рабочих экземпляров, обновлений рабочих экземпляров или масштабирования.

Рекомендации по отмене

• Вызовы, которые обрабатываются во время события перезапуска, могут быть повторены в зависимости от того, как они были вызваны. Дополнительные сведения см. в документации по повторным попыткам.

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

• Если вы не хотите, чтобы предварительно отмененные вызовы были отправлены рабочему процессу, добавьте свойство SendCanceledInvocationsToWorker в файл host.json, чтобы отключить это поведение.

  В этом примере показан host.json файл, использующий это свойство:

  {
      "version": "2.0",
      "SendCanceledInvocationsToWorker": "false"
  }
  

• Установка SendCanceledInvocationsToWorker в false может привести к исключению FunctionInvocationCanceled с следующим журналом:

  Была запрошена отмена. Запрос на вызов с идентификатором "{invocationId}" отменен и не будет отправлен работнику.

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

Асинхронное программирование

Изолированный работник .NET не задает пользовательскую SynchronizationContext. Это означает, что SynchronizationContext.Current является null во время выполнения функции. После await продолжение планируется в пуле потоков, что является стандартным поведением .NET.

Поскольку в коде функции нечего подавлять с помощью SynchronizationContext, использование ConfigureAwait(false) не имеет практического эффекта. Изолированный рабочий процесс выполняется как стандартный .NET унифицированный хост (консольное приложение), поэтому применяются те же асинхронные закономерности, основанные на async/await, которые характерны для любого приложения ASP.NET Core или консольного приложения. Это также верно для изолированных рабочих приложений .NET Framework (net48), так как рабочий процесс всегда является исполняемым файлом консоли с помощью HostBuilder.

Привязки

Определите привязки с помощью атрибутов методов, параметров и возвращаемых типов. Привязки могут предоставлять данные в виде строк, массивов и сериализуемых типов, таких как обычные объекты класса (POC). Для некоторых расширений привязки можно также привязать к типам, конкретным для службы, определенным в пакетах SDK службы.

Сведения о триггерах HTTP см. в разделе триггеров HTTP.

Полный набор эталонных примеров, использующих триггеры и привязки с изолированными функциями рабочего процесса, см. в справочном примере binding extensions reference sample.

Привязки ввода

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

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

Чтобы записать в выходную привязку, необходимо применить атрибут выходной привязки к методу функции. Этот атрибут определяет, как записывать в привязанную службу. Возвращаемое значение метода записывается в выходную привязку. Например, в следующем примере строковое значение записывается в очередь сообщений output-queue с помощью выходной привязки:

[Function(nameof(QueueInputOutputFunction))]
[QueueOutput("output-queue")]
public string[] QueueInputOutputFunction([QueueTrigger("input-queue")] Album myQueueItem, FunctionContext context)
{
    // Use a string array to return more than one message.
    string[] messages = {
        $"Album name = {myQueueItem.Name}",
        $"Album songs = {myQueueItem.Songs}"};

    _logger.LogInformation("{msg1},{msg2}", messages[0], messages[1]);

    // Queue Output messages
    return messages;
}

Несколько выходных привязок

В выходную привязку всегда записываются данные, являющиеся возвращаемым значением функции. Чтобы выполнить запись в более чем одну выходную привязку, вам понадобится создать пользовательский тип возвращаемого значения. Этот тип возвращаемого значения должен иметь атрибут выходной привязки, примененный к одному или нескольким свойствам класса. В следующем примере показана функция с триггером HTTP, использующая интеграцию ASP.NET Core и записывается в ответ HTTP и выходную привязку очереди:

public class MultipleOutputBindings
{
    private readonly ILogger<MultipleOutputBindings> _logger;

    public MultipleOutputBindings(ILogger<MultipleOutputBindings> logger)
    {
        _logger = logger;
    }

    [Function("MultipleOutputBindings")]
    public MyOutputType Run([HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequest req)
    {
        _logger.LogInformation("C# HTTP trigger function processed a request.");
        var myObject = new MyOutputType
        {
            Result = new OkObjectResult("C# HTTP trigger function processed a request."),
            MessageText = "some output"
        };
        return myObject;
    }

    public class MyOutputType
    {
        [HttpResult]
        public IActionResult Result { get; set; }

        [QueueOutput("myQueue")]
        public string MessageText { get; set; }
    }
}

При использовании пользовательских типов возвращаемых данных для нескольких выходных привязок с интеграцией ASP.NET Core необходимо добавить атрибут [HttpResult] в свойство, которое предоставляет результат. Атрибут HttpResult доступен при использовании SDK 1.17.3-preview2 или более поздней версии вместе с version 3.2.0 или более поздней версии расширения HTTP и version 1.3.0 или более поздней версии расширения ASP.NET Core.

Типы пакетов SDK

Для некоторых типов привязки для конкретной службы можно предоставить данные привязки с помощью типов пакетов SDK и платформ службы. Эти типы предлагают возможности, помимо того, что может предоставлять сериализованная строка или обычный объект CLR (POCO). Чтобы использовать новые типы, обновите проект для использования более новых версий основных зависимостей.

При локальном тестировании типов sdk на компьютере также необходимо использовать Azure Functions Core Tools версии 4.0.5000 или более поздней. Текущую func --version версию можно проверить с помощью команды.

Каждое расширение привязки также имеет собственное минимальное требование к версии, описанное в справочных статьях по расширению. В настоящее время эти расширения привязки поддерживают типы пакетов SDK:

Рекомендации по типам пакета SDK:

• При использовании выражений привязки, использующих данные триггера , нельзя использовать типы пакетов SDK для самого триггера.
• В сценариях вывода, в которых можно использовать тип SDK, создайте и работайте с клиентами SDK напрямую, а не с помощью выходной привязки.
• Триггер Azure Cosmos DB использует канал изменений Azure Cosmos DB и предоставляет элементы канала изменений в виде сериализуемых в формате JSON. В результате типы SDK не поддерживаются этим триггером.

Триггер HTTP

Триггеры HTTP позволяют вызывать функцию с помощью HTTP-запроса. Вы можете использовать два различных подхода:

• Модель интеграции ASP.NET Core, использующая понятия, знакомые разработчикам ASP.NET Core
• Встроенная модель, которая не требует дополнительных зависимостей и использует пользовательские типы для HTTP-запросов и ответов. Этот подход поддерживается для обратной совместимости с предыдущими .NET изолированными рабочими приложениями.

интеграция ASP.NET Core

В этом разделе показано, как работать с базовыми объектами HTTP-запроса и ответа с помощью типов из ASP.NET Core, включая HttpRequest, HttpResponse и IActionResult. Эта модель недоступна для приложений, предназначенных для платформы .NET Framework, которые вместо этого должны использовать встроенную модель.

Чтобы включить интеграцию ASP.NET Core для HTTP:

1. Добавьте ссылку в ваш проект на пакет Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore версии 1.0.0 или более поздней.

2. Обновите проект, чтобы использовать следующие версии пакетов:

   • Microsoft. Azure. Functions.Worker.Sdk версии 1.11.0. или позже.
   • Microsoft. Azure. Functions.Worker версии 1.16.0 или более поздней.

3. В вашем файле Program.cs обновите конфигурацию построителя хоста для вызова ConfigureFunctionsWebApplication(). Этот метод заменяет ConfigureFunctionsWorkerDefaults() , если этот метод будет использоваться в противном случае. В следующем примере показана минимальная настройка без других настроек:

   • IHostBuilder
   • IHostApplicationBuilder

   Примечание.

   Приложение должно ссылаться на версию 2.0.0 или более позднюю версию Microsoft. Azure. Functions.Worker.Extensions.Http.AspNetCore для использования интеграции ASP.NET Core с IHostApplicationBuilder.

   using Microsoft.Azure.Functions.Worker.Builder;
   using Microsoft.Extensions.Hosting;
   
   var builder = FunctionsApplication.CreateBuilder(args);
   
   builder.ConfigureFunctionsWebApplication();    
   
   builder.Build().Run();
   

4. Обновите все существующие функции с HTTP-триггером, чтобы использовать типы ASP.NET Core. В этом примере показан стандарт HttpRequest и IActionResult используется для простой функции hello, world:

   [Function("HttpFunction")]
   public IActionResult Run(
       [HttpTrigger(AuthorizationLevel.Anonymous, "get")] HttpRequest req)
   {
       return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
   }
   

Сериализация JSON с помощью интеграции ASP.NET Core

ASP.NET Core имеет собственный уровень сериализации, и он не затрагивается настройками конфигурации общей сериализации. Чтобы настроить поведение сериализации, используемое для триггеров HTTP, необходимо включить .AddMvc() вызов в рамках регистрации службы. Возвращаемый IMvcBuilder можно использовать для изменения параметров сериализации JSON ASP.NET Core.

Вы можете продолжать использовать HttpRequestData и HttpResponseData при использовании интеграции ASP.NET, хотя для большинства приложений лучше использовать HttpRequest и IActionResult. Использование HttpRequestData/HttpResponseData не вызывает уровень сериализации ASP.NET Core и вместо этого использует конфигурацию сериализации генеральной рабочей сериализации для приложения. Однако при включении интеграции ASP.NET Core может потребоваться добавить конфигурацию. Поведение по умолчанию из ASP.NET Core заключается в запрете синхронного ввода-вывода. Чтобы использовать настраиваемый сериализатор, который не поддерживает асинхронные операции ввода-вывода, например NewtonsoftJsonObjectSerializer, необходимо включить синхронные операции ввода-вывода для приложения, настроив его KestrelServerOptions.

В следующем примере показано, как настроить пакет JSON.NET (Newtonsoft.Json) и пакет NuGet Microsoft.AspNetCore.Mvc.NewtonsoftJson для сериализации с помощью этого подхода:

using Microsoft.AspNetCore.Server.Kestrel.Core;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Services.AddMvc().AddNewtonsoftJson();

// Only needed if using HttpRequestData/HttpResponseData and a serializer that doesn't support asynchronous IO
// builder.Services.Configure<KestrelServerOptions>(options => options.AllowSynchronousIO = true);

builder.Build().Run();

using Microsoft.AspNetCore.Server.Kestrel.Core;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services =>
    {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
        services.AddMvc().AddNewtonsoftJson();

        // Only needed if using HttpRequestData/HttpResponseData and a serializer that doesn't support asynchronous IO
        // services.Configure<KestrelServerOptions>(options => options.AllowSynchronousIO = true);
    })
    .Build();
host.Run();

Встроенная модель HTTP

В встроенной модели система преобразует входящее сообщение HTTP-запроса в объект HttpRequestData, который передается функции. Этот объект предоставляет данные из запроса, включая Headers, Cookies, Identitiesи URLпри необходимости сообщение Body. Этот объект представляет HTTP-запрос, но не подключен непосредственно к базовому прослушивателю HTTP или полученному сообщению.

Аналогичным образом функция возвращает объект HttpResponseData, который предоставляет данные, используемые для создания ответа HTTP, включая сообщение StatusCode, Headers и при необходимости сообщение Body.

В следующем примере показано использование HttpRequestData и HttpResponseData:

[Function(nameof(HttpFunction))]
public static HttpResponseData Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequestData req,
    FunctionContext executionContext)
{
    var logger = executionContext.GetLogger(nameof(HttpFunction));
    logger.LogInformation("message logged");

    var response = req.CreateResponse(HttpStatusCode.OK);
    response.Headers.Add("Content-Type", "text/plain; charset=utf-8");
    response.WriteString("Welcome to .NET isolated worker !!");

    return response;
}

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

Можно записывать журналы с помощью экземпляра ILogger<T> или ILogger. Вы можете получить средство ведения журнала с помощью внедрения зависимостей из ILogger<T> или из ILoggerFactory:

public class MyFunction {
    
    private readonly ILogger<MyFunction> _logger;
    
    public MyFunction(ILogger<MyFunction> logger) {
        _logger = logger;
    }
    
    [Function(nameof(MyFunction))]
    public void Run([BlobTrigger("samples-workitems/{name}", Connection = "")] string myBlob, string name)
    {
        _logger.LogInformation($"C# Blob trigger function Processed blob\n Name: {name} \n Data: {myBlob}");
    }

}

Вы также можете получить средство ведения журнала из объекта FunctionContext, который передан вашей функции. Вызовите метод GetLogger<T> или GetLogger, передав строковое значение для категории, в которой записываются журналы. Категория обычно совпадает с названием конкретной функции, из которой записываются журналы. Дополнительные сведения о категориях см. в статье мониторинга.

Используйте методы ILogger<T> и ILogger для записи различных уровней журнала, таких как LogWarning или LogError. Дополнительные сведения об уровнях журналов см. в статье мониторинга. Уровни журнала для компонентов, добавленных в код, можно настроить, регистрируя фильтры:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

// Registers IHttpClientFactory.
// By default this sends a lot of Information-level logs.
builder.Services.AddHttpClient();

// Disable IHttpClientFactory Informational logs.
// Note -- you can also remove the handler that does the logging: https://github.com/aspnet/HttpClientFactory/issues/196#issuecomment-432755765 
builder.Logging.AddFilter("System.Net.Http.HttpClient", LogLevel.Warning);
    
builder.Build().Run();

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(services =>
    {
        // Registers IHttpClientFactory.
        // By default this sends a lot of Information-level logs.
        services.AddHttpClient();
    })
    .ConfigureLogging(logging =>
    {
        // Disable IHttpClientFactory Informational logs.
        // Note -- you can also remove the handler that does the logging: https://github.com/aspnet/HttpClientFactory/issues/196#issuecomment-432755765 
        logging.AddFilter("System.Net.Http.HttpClient", LogLevel.Warning);
    })
    .Build();

В рамках настройки приложения в Program.cs можно также определить поведение для отображения ошибок в журналах. Поведение по умолчанию зависит от типа используемого создателя.

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults(builder => {}, options =>
    {
        options.EnableUserCodeException = true;
    })
    .Build();

host.Run();

Application Insights

Приложение изолированного процесса можно настроить для отправки журналов непосредственно в Application Insights. Эта конфигурация заменяет поведение по умолчанию для ретрансляции журналов через узел. Если вы не используете Aspire, настройте прямую интеграцию Application Insights, так как она дает вам контроль над тем, как создаются эти журналы.

Интеграция Application Insights по умолчанию не включена во всех интерфейсах настройки. Некоторые шаблоны создают проекты Функций с необходимыми пакетами и закомментирован код запуска. Если вы хотите использовать интеграцию Application Insights, раскомментируйте эти строки в файле Program.cs и файле project .csproj. Инструкции в остальной части этого раздела также описывают, как включить интеграцию.

Если проект является частью оркестрации Aspire, вместо этого используется OpenTelemetry для мониторинга. Не включите прямую интеграцию Application Insights в проектах Aspire. Вместо этого настройте экспортер Azure Monitor OpenTelemetry в рамках проекта значений по умолчанию службы. Если проект Functions использует интеграцию с Application Insights в контексте Aspire, приложение выдает ошибки при запуске.

Установка пакетов

Чтобы записывать журналы непосредственно в Application Insights из кода, добавьте ссылки на эти пакеты в project:

• Microsoft. Azure. Functions.Worker.ApplicationInsights версии 1.0.0 или более поздней.
• Microsoft.ApplicationInsights.WorkerService.

Выполните следующие команды, чтобы добавить эти ссылки в project:

dotnet add package Microsoft.ApplicationInsights.WorkerService
dotnet add package Microsoft.Azure.Functions.Worker.ApplicationInsights

Настройка запуска

После установки пакетов вызовите AddApplicationInsightsTelemetryWorkerService() и ConfigureFunctionsApplicationInsights() во время настройки службы в файле Program.cs, как показано в следующем примере:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
    
var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Build().Run();

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
    
var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

Вызов ConfigureFunctionsApplicationInsights() добавляет ITelemetryModule, который слушает ActivitySource, определённый функциями. Этот модуль создает данные телеметрии зависимостей, необходимые для поддержки распределенной трассировки. Дополнительные сведения о AddApplicationInsightsTelemetryWorkerService() и его использовании см. в разделе Application Insights для приложений рабочей службы.

Управление уровнями логирования

Остальная часть приложения продолжает работать с ILogger и ILogger<T>. Однако по умолчанию пакет SDK для Application Insights добавляет фильтр ведения журнала, который предписывает средству ведения журнала регистрировать только предупреждения и более серьезные ошибки. Уровни журналов можно настроить в изолированном рабочем процессе одним из следующих способов:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Logging.Services.Configure<LoggerFilterOptions>(options =>
    {
        LoggerFilterRule? defaultRule = options.Rules.FirstOrDefault(rule => rule.ProviderName
            == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
        if (defaultRule is not null)
        {
            options.Rules.Remove(defaultRule);
        }
    });

builder.Build().Run();

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .ConfigureLogging(logging =>
    {
        logging.Services.Configure<LoggerFilterOptions>(options =>
        {
            LoggerFilterRule? defaultRule = options.Rules.FirstOrDefault(rule => rule.ProviderName
                == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
            if (defaultRule is not null)
            {
                options.Rules.Remove(defaultRule);
            }
        });
    })
    .Build();

host.Run();

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information",
      "Microsoft.Azure.Functions.Worker": "Information"
    },
    "ApplicationInsights": {
      "LogLevel": {
        "Default": "Information"
      }
    }
  }
}

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Build().Run();

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureAppConfiguration(config =>
    {
        config.SetBasePath(Directory.GetCurrentDirectory())
              .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
              .AddEnvironmentVariables();
    })
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information",
      "Microsoft.Azure.Functions.Worker": "Information"
    },
    "ApplicationInsights": {
      "LogLevel": {
        "Default": "Information"
      }
    }
  }
}

Дополнительные сведения о настройке логирования см. в разделе Logging в .NET и Application Insights для приложений рабочей службы.

Оптимизация производительности

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

В общем случае приложение должно использовать последние версии его основных зависимостей. Как минимум обновите project следующим образом:

1. Обновление Microsoft. Azure. Functions.Worker версии 1.19.0 или более поздней.
2. Обновление Microsoft. Azure. Functions.Worker.Sdk версии 1.16.4 или более поздней.
3. Добавьте ссылку на платформу Microsoft.AspNetCore.App, если приложение не предназначено для .NET Framework.

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

  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.16.4" />
  </ItemGroup>

Заполнители

Заполнители — это возможность платформы, которая улучшает холодный запуск приложений, предназначенных для .NET 6 или более поздних версий. Чтобы использовать эту оптимизацию, необходимо явно включить заполнители, выполнив следующие действия.

1. Обновите конфигурацию project, чтобы использовать последние версии зависимостей, как описано в предыдущем разделе.

2. Установите настройку приложения WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED на 1. Используйте эту команду az functionapp config appsettings set:

   az functionapp config appsettings set -g <groupName> -n <appName> --settings 'WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED=1'
   

   В этом примере замените <groupName> имя группы ресурсов и замените <appName> именем приложения-функции.

3. Убедитесь, что свойство netFrameworkVersion функционального приложения соответствует целевому фреймворку вашего проекта, который должен быть .NET 6 или более поздней версии. Используйте эту команду az functionapp config set:

   az functionapp config set -g <groupName> -n <appName> --net-framework-version <framework>
   

   В этом примере также замените <framework> соответствующей строкой версии, например v8.0, в соответствии с целевой версией .NET.

4. Убедитесь, что приложение-функция настроено на использование 64-разрядного процесса. Используйте эту команду az functionapp config set:

   az functionapp config set -g <groupName> -n <appName> --use-32bit-worker-process false
   

Оптимизированный выполняющий компонент

Исполнитель функции — это компонент платформы, которая вызывает вызовы. Оптимизированная версия этого компонента включена по умолчанию начиная с версии 1.16.2 пакета SDK. Дальнейшая настройка не требуется.

ReadyToRun

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

ReadyToRun требует создания проекта с учётом архитектуры среды выполнения хост-приложения. Если эти архитектуры не выровнены, приложение обнаруживает ошибку при запуске. Выберите идентификатор среды выполнения из этой таблицы:

¹ Только 64-разрядные приложения имеют право на некоторые другие оптимизации производительности.

Чтобы проверить, является ли Windows app 32-разрядной или 64-разрядной, выполните следующую команду CLI, заменив <group_name> именем группы ресурсов и <app_name> именем приложения. Выходные данные true указывают на то, что приложение имеет 32-разрядную версию, а значение false — 64-разрядную версию.

 az functionapp config show -g <group_name> -n <app_name> --query "use32BitWorkerProcess"

Вы можете изменить версию своего приложения на 64-разрядную с помощью следующей команды, используя те же подстановки.

az functionapp config set -g <group_name> -n <app_name> --use-32bit-worker-process false`

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

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

Если вы не хотите задавать <RuntimeIdentifier> в составе файла проекта, этот параметр можно также настроить как часть самого процесса публикации. Например, для Windows-приложения с функциями 64-разрядной версии команда .NET CLI следующая:

dotnet publish --runtime win-x64

В Visual Studio задайте параметр Target Runtime в профиле публикации на правильный идентификатор среды выполнения. Если задано значение по умолчанию Portable, ReadyToRun не используется.

Развертывание в Azure Functions

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

Вы также можете разместить приложение-функцию в контейнере Linux. Дополнительные сведения см. в разделе Работа с контейнерами и Azure Functions.

Создание ресурсов Azure

Вы можете создать приложение-функцию и другие необходимые ресурсы в Azure с помощью одного из следующих методов:

• Visual Studio: Visual Studio может создавать ресурсы для вас во время процесса публикации кода.
• Visual Studio Code: Visual Studio Code может подключаться к подписке, создавать ресурсы, необходимые приложению, а затем публиковать код.
• Azure CLI. Используйте Azure CLI для создания необходимых ресурсов в Azure.
• Azure PowerShell. Используйте Azure PowerShell для создания необходимых ресурсов в Azure.
• Deployment templates. Используйте шаблоны ARM и файлы Bicep для автоматизации развертывания необходимых ресурсов для Azure. Убедитесь, что шаблон содержит все необходимые параметры.
• Azure portal: создайте необходимые ресурсы в Azure portal.

Публикация приложения

После создания приложения-функции и других необходимых ресурсов в Azure разверните код проекта в Azure с помощью одного из этих методов:

• Visual Studio: простое развертывание вручную во время разработки.
• Visual Studio Code: простое развертывание вручную во время разработки.
• Azure Functions Core Tools: развернуть файл проекта из командной строки.
• Непрерывное развертывание: полезно для постоянного обслуживания, часто в промежуточный слот.
• Шаблоны развертывания. Для автоматизации развертываний пакетов можно использовать шаблоны ARM или файлы Bicep.

Для получения дополнительной информации см. раздел Технологии развертывания в Azure Functions.

Полезная нагрузка для развертывания

Многие методы развертывания используют ZIP-архив. Если вы создаете zip-архив самостоятельно, оно должно соответствовать структуре, описанной в этом разделе. Если это не так, ваше приложение может столкнуться с ошибками при запуске.

Нагрузка для развертывания должна соответствовать результату выполнения команды dotnet publish, но без включающей родительской папки. Zip-архив должен быть сделан из следующих файлов:

• .azurefunctions/
• extensions.json
• functions.metadata
• host.json
• worker.config.json
• Исполняемый файл вашего проекта (консольное приложение)
• Другие вспомогательные файлы и каталоги находятся на одном уровне с этим исполняемым файлом.

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

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

Требования к развертыванию

Для выполнения .NET функций в изолированной рабочей модели в Azure необходимо выполнить несколько требований. Требования зависят от операционной системы:

При создании приложения-функции в Azure с помощью методов, описанных в предыдущем разделе, эти необходимые параметры добавляются для вас. При создании этих ресурсов с помощью шаблонов ARM или файлов Bicep для автоматизации необходимо задать их в шаблоне.

Aspire

Aspire — это стек с готовыми решениями, упрощающий разработку распределенных приложений в облаке. Вы можете включать изолированные проекты модели рабочих в оркестрацию Aspire 13. Дополнительные сведения см. в Azure Functions и Aspire.

Отладка

При локальном использовании Visual Studio или Visual Studio Code вы можете выполнять отладку .NET изолированного рабочего проекта как обычно. Однако существует два сценария отладки, которые не работают должным образом.

Удаленная отладка с помощью Visual Studio

Так как приложение изолированного рабочего процесса выполняется вне среды выполнения Функций, необходимо подключить удаленный отладчик к отдельному процессу. Дополнительные сведения об отладке с помощью Visual Studio см. в статье Remote Debugging.

Отладка при выборе платформы .NET Framework

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

Приложение должно начинаться с вызова FunctionsDebugger.Enable(); в качестве первой операции. Это происходит в методе Main() перед инициализацией HostBuilder. Файл Program.cs должен выглядеть следующим образом:

using System;
using System.Diagnostics;
using Microsoft.Extensions.Hosting;
using Microsoft.Azure.Functions.Worker;
using NetFxWorker;

namespace MyDotnetFrameworkProject
{
    internal class Program
    {
        static void Main(string[] args)
        {
            FunctionsDebugger.Enable();

            var host = FunctionsApplication
                .CreateBuilder(args)
                .Build();

            host.Run();
        }
    }
}

using System;
using System.Diagnostics;
using Microsoft.Extensions.Hosting;
using Microsoft.Azure.Functions.Worker;
using NetFxWorker;

namespace MyDotnetFrameworkProject
{
    internal class Program
    {
        static void Main(string[] args)
        {
            FunctionsDebugger.Enable();

            var host = new HostBuilder()
                .ConfigureFunctionsWorkerDefaults()
                .Build();

            host.Run();
        }
    }
}

Затем необходимо вручную подключиться к процессу с помощью отладчика .NET Framework. Visual Studio автоматически не выполняет это для приложений .NET Framework с изолированным рабочим процессом, и следует избегать операции "Начать отладку".

В каталоге project (или в выходном каталоге сборки) выполните следующую команду:

func host start --dotnet-isolated-debug

Это запускает рабочий процесс, и процесс останавливается со следующим сообщением:

Azure Functions .NET Worker (PID: <process id>) initialized in debug mode. Waiting for debugger to attach...

Где <process id> — идентификатор рабочего процесса. Теперь вы можете использовать Visual Studio для ручного подключения к процессу. Инструкции по этой операции см. в разделе Подключение к запущенному процессу.

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

Предварительный просмотр версий .NET

До общедоступного выпуска версия .NET может быть выпущена в состоянии Preview или Go-live. Дополнительные сведения об этих состояниях см. в политике официальной поддержки .NET.

Хотя может оказаться возможным использовать указанный выпуск из локального проекта функций, функциональные приложения, размещенные в Azure, могут не иметь этого выпуска. Azure Functions можно использовать только с предварительными версиями или выпусками Go-live, упомянутыми в этом разделе.

Azure Functions в настоящее время не работает с выпусками "Предварительная версия" или "Go-live .NET". Список общедоступных выпусков, которые можно использовать, см. в поддерживаемых версиях .

Использование пакета SDK для предварительной версии .NET

Чтобы использовать Azure Functions с предварительной версией .NET, необходимо обновить project следующим образом:

1. Установка соответствующей версии пакета SDK .NET в разработке
2. Изменение параметра TargetFramework в файле .csproj

При развертывании функционального приложения в Azure также необходимо убедиться, что фреймворк предоставлен приложению. В течение периода предварительного просмотра некоторые средства и возможности могут не отображать новую предварительную версию в качестве опции. Если вы не видите предварительную версию, включенную в Azure portal, например, можно использовать REST API, файлы Bicep или Azure CLI для настройки версии вручную.

az functionapp config set -g <groupName> -n <appName> --net-framework-version <framework>

az functionapp config set -g <groupName> -n <appName> --linux-fx-version "dotnet-isolated|<version>"

Рекомендации по использованию .NET предварительных версий

При использовании функций с предварительными версиями .NET следует учитывать следующие рекомендации.

• При создании функций в Visual Studio необходимо использовать Visual Studio Insiders, которая поддерживает создание проектов Azure Functions с предварительными версиями SDK .NET.

• Убедитесь, что у вас есть последние инструменты и шаблоны функций. Чтобы обновить ваши инструменты, следуйте этим шагам:

  1. Перейдите к Tools>Options Выберите Azure Functions в разделе Projects и Solutions>More Settings.
  2. Выберите "Проверить наличие обновлений " и установить обновления по запросу.

• В течение предварительного периода в вашей среде разработки может быть более новая версия предварительной версии .NET, чем в размещенной службе. Это может привести к сбою функционального приложения при развертывании. Для этого можно указать версию пакета SDK, которую нужно использовать в global.json.

  1. dotnet --list-sdks Выполните команду и запишите предварительную версию, которую вы используете в настоящее время во время локальной разработки.
  2. Выполните команду dotnet new globaljson --sdk-version <SDK_VERSION> --force, где <SDK_VERSION> обозначает используемую локально версию. Например, dotnet new globaljson --sdk-version dotnet-sdk-10.0.100-preview.5.25277.114 --force заставляет систему использовать SDK .NET 10 предварительная версия 5 при сборке вашего проекта.

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