Поделиться через

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

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

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

Начало работы Основные понятия Примеры

Чтобы узнать о развертывании проекта с изолированной моделью работника в Azure, см. Развертывание в Функции Azure.

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

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

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

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

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

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

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

Примечание.

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

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

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

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

2 Процесс сборки также требует пакета SDK для .NET.

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

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

Следите за Анонсами службы приложений Azure для получения последних новостей о выпусках "Функций Azure", включая удаление отдельных устаревших промежуточных версий.

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

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

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

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

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

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

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

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

Версия 2.x

Версии 2.x основных пакетов изменяют поддерживаемые платформы и поддерживают новые API .NET из этих более поздних версий. Если вы нацелены на .NET 9 или более поздней версии, приложение должно ссылаться на версии 2.0.0 или более поздней версии обоих пакетов.

При обновлении до версий 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 можно гораздо проще добавлять конфигурации, внедрять зависимости и запускать собственное ПО промежуточного слоя.

В коде ниже приведен пример конвейера HostBuilder:

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();

Для этого кода требуется using Microsoft.Extensions.DependencyInjection;.

Перед вызовом Build() на IHostBuilder, необходимо выполнить следующие действия.

  • Вызовите ConfigureFunctionsWebApplication(), если используете интеграцию ASP.NET Core, или вызовите ConfigureFunctionsWorkerDefaults() иначе. Дополнительные сведения об этих параметрах см. в разделе HTTP триггера.
    Если вы пишете приложение с помощью F#, для некоторых расширений триггеров и привязок требуется дополнительная настройка. См. документацию по настройке расширения Blob, Таблиц и Cosmos DB, если вы планируете использовать эти расширения в приложении F#.
  • Настройте все службы или конфигурацию приложения, необходимые для проекта. Дополнительные сведения см. в разделе "Конфигурация ".
    Если вы планируете использовать Application Insights, необходимо вызвать AddApplicationInsightsTelemetryWorkerService() и ConfigureFunctionsApplicationInsights() в делегате ConfigureServices() . Дополнительные сведения см. в Application Insights .

Если проект предназначен для .NET Framework 4.8, необходимо также добавить FunctionsDebugger.Enable(); перед созданием HostBuilder. Это должна быть первая строка метода Main(). Дополнительные сведения см. в статье Отладка при выборе платформа .NET Framework.

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

await host.RunAsync();

Настройка

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

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

  • Набор преобразователей по умолчанию.
  • Настройте параметр JsonSerializerOptions по умолчанию таким образом, чтобы он игнорировал регистр в именах свойств.
  • Интеграция с ведением журнала Функций Azure.
  • Функции и промежуточное ПО для выходного связывания.
  • Промежуточное программное обеспечение для выполнения функций.
  • Поддержка gRPC по умолчанию.
.ConfigureFunctionsWorkerDefaults()

Поскольку у вас есть доступ к конвейеру сборки узла, во время инициализации вы также можете настроить особые конфигурации для приложения. Метод ConfigureAppConfiguration можно вызвать на HostBuilder однократно или многократно, чтобы добавить любые источники конфигурации, необходимые для вашего кода. Подробнее о конфигурации приложения см. в разделе Конфигурация в ASP.NET Core.

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

Примечание.

Пользовательские источники конфигурации нельзя использовать для настройки триггеров и привязок. Конфигурация триггера и привязки должна быть доступна для платформы Функций, а не только для кода приложения. Эту конфигурацию можно предоставить с помощью параметров приложения, ссылок на Key Vault или ссылок на App Configuration.

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

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

При использовании HostBuilder, вызовите ConfigureServices на объекте построителя хоста и используйте методы расширения в IServiceCollection для внедрения определенных служб. В следующем примере показано, как внедряется зависимость отдельной службы.

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

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

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

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

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> в данном примере также был получен с помощью внедрения зависимостей, поэтому он регистрируется автоматически. Дополнительные сведения о параметрах конфигурации для ведения журнала см. в разделе "Ведение журнала".

Совет

В примере используется литеральная строка для имени клиента как в Program.cs, так и в функции. Вместо этого следует использовать общую строку констант, определенную в классе функции. Например, можно добавить public const string CopyStorageClientName = nameof(_copyContainerClient); и затем ссылаться на BlobCopier.CopyStorageClientName в обоих местах. Можно также определить имя раздела конфигурации с функцией, а не в Program.cs.

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

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

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

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 упрощают работу с ПО промежуточного слоя в изолированной модели.

Метод Описание
GetHttpRequestDataAsync Возвращает экземпляр HttpRequestData при вызове триггером HTTP. Этот метод возвращает экземпляр ValueTask<HttpRequestData?>, который полезен при чтении данных сообщения, таких как заголовки запросов и файлы cookie.
GetHttpResponseData Возвращает экземпляр HttpResponseData при вызове триггером HTTP.
GetInvocationResult Возвращает экземпляр InvocationResult, представляющий результат выполнения текущей функции. Используйте свойство Value, чтобы получить или задать значение по мере необходимости.
GetOutputBindings Возвращает записи выходной привязки для текущего выполнения функции. Каждая запись в результате этого метода относится к типу OutputBindingData. Вы можете использовать свойство Value, чтобы получить или задать значение по мере необходимости.
BindInputAsync Привязывает элемент привязки входных данных для запрошенного экземпляра BindingMetadata. Например, когда у вас есть функция с BlobInput входной привязкой, которая должна использоваться промежуточным ПО.

Это пример реализации ПО промежуточного слоя, которая считывает 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 и использует его для пометки заголовка ответа. Для более полного примера использования пользовательского ПО промежуточного слоя в вашем приложении-функции, см. пример пользовательского ПО промежуточного слоя.

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

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

В следующем примере показано использование ConfigureFunctionsWebApplication, но оно также будет работать для ConfigureFunctionsWorkerDefaults:

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.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(QueueFunction))]
[QueueOutput("output-queue")]
public string[] Run([QueueTrigger("input-queue")] Album myQueueItem, FunctionContext context)

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

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

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

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

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

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

При изоляции .NET передает объект 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);
    }
}

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

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

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

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

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

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

Внимание

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

Cancellation has been requested. The invocation request with id '{invocationId}' is canceled and will not be sent to the worker

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

Привязки

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

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

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

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

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

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

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

[Function(nameof(QueueFunction))]
[QueueOutput("output-queue")]
public string[] Run([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 или более поздней версии, а также версии 3.2.0 или более поздней версии расширения HTTP и версии 1.3.0 или более поздней версии расширения ASP.NET Core.

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

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

Зависимость Требование к версии
Microsoft.Azure.Functions.Worker 1.18.0 или новее
Microsoft.Azure.Functions.Worker.Sdk 1.13.0 или выше

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

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

Сервис Триггер Входные привязки Выходные привязки
Блобы Azure Общедоступная версия Общедоступная версия Типы пакетов SDK не рекомендуется.1
Очереди Azure Общедоступная версия Входная привязка не существует Типы пакетов SDK не рекомендуется.1
Сервисная шина Azure Общедоступная версия Входная привязка не существует Типы пакетов SDK не рекомендуется.1
Центры событий Azure Общедоступная версия Входная привязка не существует Типы пакетов SDK не рекомендуется.1
Azure Cosmos DB Типы пакетов SDK не используются2 Общедоступная версия Типы пакетов SDK не рекомендуется.1
Таблицы Azure Триггер не существует Общедоступная версия Типы пакетов SDK не рекомендуется.1
Сетка событий Azure Общедоступная версия Входная привязка не существует Типы пакетов SDK не рекомендуется.1

1 Для выходных сценариев, в которых используется тип пакета SDK, следует создавать и работать с клиентами SDK непосредственно вместо использования выходной привязки. Пример внедрения зависимостей см. в разделе "Регистрация клиентов Azure".

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

Примечание.

При использовании выражений привязки, использующих данные триггера , нельзя использовать типы пакетов 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 предоставляются этой моделью. В частности, конвейер промежуточного программного обеспечения ASP.NET Core и возможности маршрутизации недоступны. ASP.NET интеграция Core требует использования обновленных пакетов.

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

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

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

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

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

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

host.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.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, передав строковое значение, которое является именем категории, в которой записываются журналы. Категория обычно совпадает с названием конкретной функции, из которой записываются журналы. Подробнее о категориях см. в статье об отслеживании.

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

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 можно также определить поведение для отображения ошибок в журналах. Поведение по умолчанию зависит от типа используемого создателя.

При использовании HostBuilder по умолчанию исключения, вызываемые вашим кодом, могут обернуться в RpcException. Чтобы удалить этот дополнительный слой, задайте EnableUserCodeException для свойства значение true в рамках настройки построителя:

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. Это заменяет поведение по умолчанию для ретрансляции журналов через хост. Если вы не используете .NET Aspire, рекомендуется настроить прямую интеграцию Application Insights, так как она позволяет управлять тем, как создаются эти журналы.

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

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

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

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

Чтобы добавить эти ссылки в проект, можно выполнить следующие команды:

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.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 для приложений службы рабочих процессов.

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

Внимание

Узел функций и изолированный процесс имеют отдельную конфигурацию для уровней логирования и т. д. Любая конфигурация Application Insights в host.json не повлияет на логирование из процесса, и аналогично, конфигурация в коде процесса не будет влиять на логирование из узла. Необходимо применить изменения в обоих местах, если сценарий требует настройки на обоих уровнях.

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

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();

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

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

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

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

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

  <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. Обновите конфигурацию проекта, чтобы использовать последние версии зависимостей, как описано в предыдущем разделе.

  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

Внимание

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

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

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

ReadyToRun

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

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

Операционная система Приложение 32-битное1 Идентификатор среды выполнения
Виндоус Истина win-x86
Виндоус Ложно win-x64
Линукс Истина Не поддерживается.
Линукс Ложно linux-x64

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

Чтобы проверить, имеет ли приложение Windows 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`

Чтобы скомпилировать проект как ReadyToRun, обновите файл проекта, добавив элементы <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 параметр целевой среды выполнения в профиле публикации должен иметь правильный идентификатор среды выполнения. Если задано значение по умолчанию Portable, ReadyToRun не используется.

Развертывание в Функции Azure

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Переменная FUNCTIONS_WORKER_RUNTIME должна быть установлена в значение dotnet-isolated.
  • netFrameworkVersion должен быть установлен на нужную версию.

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

.NET Aspire (предварительная версия)

.NET Aspire — это предпочительный стек, упрощающий разработку распределенных приложений в облаке. Вы можете подключить проекты изолированной рабочей модели .NET 8 и .NET 9 в оркестрации Aspire 9.0, используя предварительную поддержку. См. функции Azure на .NET Aspire (предварительная версия) для получения дополнительной информации.

Отладка

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

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

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

Отладка при работе с .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 = new HostBuilder()
                .ConfigureFunctionsWorkerDefaults()
                .Build();

            host.Run();
        }
    }
}

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

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

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 может быть выпущена в режиме предварительной версии или в режиме go-live. Дополнительные сведения об этих состояниях см. в политике поддержки .NET.

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

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

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

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

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

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

Для приложений, размещенных в Windows, используйте следующую команду Azure CLI. Замените <groupName> именем группы ресурсов и замените <appName> именем приложения-функции. Замените <framework> на соответствующую строку версии, например v8.0.

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

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

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

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

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

    1. Перейдите к параметрам инструментов>, выберите Функции Azure в разделе "Проекты и решения".
    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-8.0.100-preview.7.23376.3 --force вызывает использование системой пакета SDK .NET 8 Preview 7 при сборке вашего проекта.

Примечание.

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

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

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

Перенос приложений .NET в изолированную рабочую модель

Интеграция с .NET Aspire