Guia para executar o C# Azure Functions no modelo de trabalho isolado

Este artigo apresenta o trabalho com Azure Functions em .NET usando o modelo de trabalhador isolado. Este modelo permite que o seu projeto aponte versões do .NET independentemente de outros componentes de runtime. Para obter informações sobre versões específicas do .NET suportadas, consulte a versão suportada.

Use os links a seguir para começar imediatamente a criar funções de modelo de trabalho isoladas do .NET.

Para saber como implementar um projeto de modelo de trabalhador isolado para Azure, consulte Deploy to Azure Functions.

Benefícios do modelo de trabalhador isolado

Pode executar as funções da sua biblioteca de classes .NET em dois modos: ou no mesmo processo que o runtime host das Funções (em processo) ou num processo worker isolado. Quando suas funções .NET são executadas em um processo de trabalho isolado, você pode aproveitar os seguintes benefícios:

• Menos conflitos: como suas funções são executadas em um processo separado, os assemblies usados em seu aplicativo não entram em conflito com versões diferentes dos mesmos assemblies usados pelo processo de host.
• Controle total do processo: você controla a inicialização do aplicativo, o que significa que você pode gerenciar as configurações usadas e o middleware iniciado.
• Injeção de dependência padrão: Como você tem controle total do processo, pode usar os comportamentos atuais do .NET para injeção de dependência e incorporar middleware em seu aplicativo de função.
• Flexibilidade de versão do .NET: A execução fora do processo do host significa que suas funções podem ser executadas em versões do .NET não suportadas nativamente pelo tempo de execução do Functions, incluindo o .NET Framework.

Se você tiver um aplicativo de função C# existente que seja executado em processo, precisará migrar seu aplicativo para aproveitar esses benefícios. Para obter mais informações, consulte Migrar aplicativos .NET do modelo em processo para o modelo de trabalho isolado.

Para obter uma comparação abrangente entre os dois modos, consulte Diferenças entre o processo de trabalho em processo e o processo de trabalho isolado .NET Azure Functions.

Versões suportadas

As versões do tempo de execução do Functions suportam versões específicas do .NET. Para saber mais sobre as versões do Functions, consulte Visão geral das versões de tempo de execução do Azure Functions. O suporte à versão também depende se suas funções são executadas no processo ou no processo de trabalho isolado.

A tabela a seguir mostra o nível mais alto de .NET ou .NET Framework que pode ser usado com uma versão específica do Functions.

1 O .NET 6 era anteriormente suportado em ambos os modelos, mas chegou ao fim do suporte oficial em 12 de novembro de 2024. O .NET 7 era anteriormente suportado no modelo de trabalhador isolado, mas chegou ao fim do suporte oficial em 14 de maio de 2024.

2 O processo de compilação também requer o SDK do .NET.

3 O suporte termina para a versão 1.x do tempo de execução do Azure Functions em 14 de setembro de 2026. Para obter mais informações, consulte este anúncio de suporte. Para obter suporte total contínuo, você deve migrar seus aplicativos para a versão 4.x.

4 O suporte para o modelo em processo termina em 10 de novembro de 2026. Para obter mais informações, consulte este anúncio de suporte. Para obter suporte total contínuo, você deve migrar seus aplicativos para o modelo de trabalho isolado.

⁵ Não podes executar aplicações .NET 10 no Linux no plano Consumo. Para rodar no Linux, você deve usar o plano Flex Consumption.

Para obter as últimas notícias sobre as versões do Azure Functions, incluindo a remoção de versões secundárias mais antigas específicas, monitore os anúncios do Serviço de Aplicativo do Azure.

Estrutura do projeto

Um projeto .NET para Azure Functions que utiliza o modelo de trabalhador isolado é basicamente um projeto de consola .NET que visa um runtime .NET suportado. Os seguintes ficheiros são os ficheiros básicos necessários em qualquer projeto isolado .NET:

• Arquivo de projeto C# (.csproj) que define o projeto e as dependências.
• Program.cs arquivo que é o ponto de entrada para o aplicativo.
• Todos os arquivos de código que definem suas funções.
• host.json arquivo que define a configuração compartilhada por funções em seu projeto.
• local.settings.json arquivo que define as variáveis de ambiente usadas pelo seu projeto quando executado localmente em sua máquina.

Para obter exemplos completos, consulte o projeto de exemplo do .NET 8 e o projeto de exemplo do .NET Framework 4.8.

Referências de pacotes

Um projeto .NET para Azure Functions que utiliza o modelo de trabalhador isolado utiliza um conjunto único de pacotes tanto para funcionalidades principais como para extensões de binding.

Pacotes principais

Para executar as suas funções .NET num processo worker isolado, precisa dos seguintes pacotes:

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

As versões mínimas destes pacotes dependem da sua versão .NET de destino:

Versão 2.x

As versões 2.x dos pacotes principais alteram as estruturas suportadas e trazem suporte para novas APIs .NET dessas versões posteriores. Ao atualizar para as versões 2.x, observe as seguintes alterações:

• A partir da versão 2.0.0 do Microsoft.Azure.Functions.Worker.Sdk:
  • O SDK inclui configurações padrão para compilações de contêiner do SDK.
  • O SDK inclui suporte para dotnet run quando as Ferramentas Principais do Azure Functions estão instaladas. No Windows, instala as Ferramentas Centrais através de um mecanismo diferente do NPM.
• A partir da versão 2.0.0 do Microsoft.Azure.Functions.Worker:
  • Esta versão adiciona suporte para IHostApplicationBuilder. Alguns exemplos neste guia incluem guias para mostrar alternativas usando IHostApplicationBuildero . Estes exemplos requerem as versões 2.x.
  • A validação do escopo do provedor de serviços é incluída por padrão se executada em um ambiente de desenvolvimento. Esse comportamento corresponde ASP.NET Core.
  • A EnableUserCodeException opção está ativada por padrão. A propriedade está agora marcada como obsoleta.
  • A IncludeEmptyEntriesInMessagePayload opção está ativada por padrão. Com essa opção ativada, as cargas úteis de gatilho que representam coleções sempre incluem entradas vazias. Por exemplo, se uma mensagem for enviada sem corpo, uma entrada vazia ainda está presente em string[] nos dados de disparo. A inclusão de entradas vazias facilita o cruzamento com matrizes de metadados que a função também pode referenciar. Você pode desabilitar esse comportamento definindo IncludeEmptyEntriesInMessagePayload como false na configuração do WorkerOptions serviço.
  • A ILoggerExtensions classe é renomeada para FunctionsLoggerExtensions. A renomeação evita um erro de chamada ambígua ao usar LogMetric() em uma ILogger instância.
  • Para aplicações que usam HttpResponseData, o WriteAsJsonAsync() método já não define o código de estado para 200 OK. Na 1.x, este comportamento sobrepunha outros códigos de erro que definiste.
• As versões 2.x descartam o suporte ao .NET 5 TFM.

Pacotes de extensão

Como as funções de processo de trabalho isoladas do .NET usam tipos de vinculação diferentes, elas exigem um conjunto exclusivo de pacotes de extensão de vinculação.

Você encontra esses pacotes de extensão em Microsoft.Azure.Functions.Worker.Extensions.

Arranque e configuração

Ao usar o modelo de trabalho isolado, você tem acesso à inicialização do seu aplicativo de função, que geralmente está em Program.cs. Você é responsável por criar e iniciar sua própria instância de host. Como tal, você também tem acesso direto ao pipeline de configuração do seu aplicativo. Com o processo de trabalho isolado do .NET Functions, você pode adicionar configurações muito mais facilmente, injetar dependências e executar seu próprio middleware.

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://v4.hkg1.meaqua.org/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://v4.hkg1.meaqua.org/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();

await host.RunAsync();

Configuração

O tipo de construtor que usa determina como configura a aplicação.

.ConfigureFunctionsWorkerDefaults()

Estas configurações aplicam-se apenas ao código de trabalhador que escreves. Eles não influenciam diretamente a configuração do anfitrião das Funções, nem os gatilhos e associações. Para fazer alterações ao host de funções ou à configuração de disparador e ligação, use o ficheiro host.json.

Injeção de dependência

O modelo de trabalhador isolado usa mecanismos .NET padrão para injetar serviços.

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

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

Este código requer using Microsoft.Extensions.DependencyInjection;. Para saber mais, consulte Injeção de dependência no ASP.NET Core.

Registrar clientes do Azure

Use injeção de dependências para interagir com outros serviços Azure. Pode injetar clientes a partir do Azure SDK para .NET usando o pacote Microsoft.Extensions.Azure . Depois de instalar o pacote, registre os clientes chamando AddAzureClients() a coleção de serviços em Program.cs. O exemplo a seguir configura um cliente nomeado para Blobs do 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();

O exemplo seguinte mostra como pode usar estes tipos de registo e SDK para copiar o conteúdo do blob como um fluxo de um contentor para outro, usando um cliente injetado:

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!");
        }

    }
}

O ILogger<T> neste exemplo também é obtido através de injeção de dependência, por isso é registado automaticamente. Para saber mais sobre as opções de configuração para registro em log, consulte Logging.

Middleware

O modelo de trabalhador isolado também suporta o registro de middleware, novamente usando um modelo semelhante ao que existe no ASP.NET. Esse modelo oferece a capacidade de injetar lógica no pipeline de invocação e executar funções antes e depois.

O método de extensão ConfigureFunctionsWorkerDefaults tem uma sobrecarga que permite registar o seu próprio middleware, como vê no exemplo seguinte.

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

O UseWhen método de extensão regista um middleware que é executado condicionalmente. Deve passar um predicado que retorne um valor booleano a este método. O middleware participa no pipeline de processamento de invocações quando o predicado retorna true.

Os seguintes métodos de extensão em FunctionContext facilitam o trabalho com middleware no modelo isolado.

Este exemplo mostra uma implementação de middleware que lê a HttpRequestData instância e atualiza a HttpResponseData instância durante a execução da função:

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

Este middleware verifica a presença de um cabeçalho de pedido específico (x-correlationId). Quando o cabeçalho está presente, o middleware usa o valor do cabeçalho para carimbar um cabeçalho de resposta. Caso contrário, gera um novo valor GUID e usa esse valor para carimbar o cabeçalho da resposta.

Para obter um exemplo mais completo de uso de middleware personalizado em seu aplicativo de função, consulte o exemplo de referência de middleware personalizado.

Personalizando a serialização JSON

O modelo de trabalhador isolado usa System.Text.Json por padrão. Você pode personalizar o comportamento do serializador configurando serviços como parte do seu Program.cs arquivo. Esta seção aborda a serialização de uso geral e não influencia a serialização JSON de trigger de HTTP com integração ao ASP.NET Core, que deve ser configurada separadamente.

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

Para usar JSON.NET (Newtonsoft.Json) para serialização, instale o Microsoft.Azure.Core.NewtonsoftJson pacote. Depois, no seu registo de serviço, reatribua a propriedade Serializer sobre a configuração WorkerOptions. O exemplo seguinte mostra esta configuração usando ConfigureFunctionsWebApplication, mas também funciona para 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();

Métodos reconhecidos como funções

Um método de função é um método público de uma classe pública com um Function atributo aplicado ao método e um atributo trigger aplicado a um parâmetro de entrada, conforme mostrado no exemplo a seguir:

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

O atributo trigger especifica o tipo de gatilho e vincula os dados de entrada a um parâmetro de método. A função de exemplo anterior é ativada por uma mensagem de fila, e a mensagem de fila é passada para o método no myQueueItem parâmetro.

O Function atributo marca o método como um ponto de entrada de função. O nome deve ser único dentro de um projeto, começar por uma letra e conter apenas letras, números, _, e -, com até 127 caracteres de extensão. Os modelos de projeto geralmente criam um método chamado Run, mas o nome do método pode ser qualquer nome de método C# válido. O método deve ser um membro público de uma classe pública. Geralmente, deve ser um método de instância para que os serviços possam ser transmitidos por meio de injeção de dependência.

Parâmetros de função

Aqui estão alguns dos parâmetros que você pode incluir como parte de uma assinatura de método de função:

• Ligações, que são marcadas como tal, decorando os parâmetros como atributos. A função deve conter exatamente um parâmetro de gatilho.
• Um objeto de contexto de execução, que fornece informações sobre a invocação atual.
• Um token de cancelamento, usado para desligamento suave.

Contexto de execução

No modelo de trabalhador isolado, o processo trabalhador passa um objeto FunctionContext aos seus métodos de função. Esse objeto permite que você obtenha uma ILogger instância para gravar nos logs chamando o método GetLogger e fornecendo uma categoryName cadeia de caracteres. Você pode usar esse contexto para obter um ILogger sem ter que usar a injeção de dependência. Para obter mais informações, consulte Logging.

Tokens de cancelamento

Uma função pode aceitar um parâmetro cancellationToken , que permite que o sistema operacional notifique seu código quando a função estiver prestes a ser encerrada. Você pode usar essa notificação para garantir que a função não seja encerrada inesperadamente de uma forma que deixe os dados em um estado inconsistente.

As funções .NET que executam num processo de trabalho isolado suportam tokens de cancelamento. O exemplo a seguir gera uma exceção quando uma solicitação de cancelamento é recebida:

[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);
    }
}

O exemplo a seguir executa ações de limpeza quando uma solicitação de cancelamento é recebida:

[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);
    }
}

Cenários que levam ao cancelamento

O token de cancelamento é sinalizado quando a invocação da função é cancelada. Várias razões podem levar ao cancelamento, e essas razões variam consoante o tipo de gatilho utilizado. Algumas razões comuns são:

• Desconexão do cliente: O cliente que está a invocar a sua função desliga-se. Esta razão deve-se provavelmente a funções de gatilho HTTP.
• Reinício da aplicação de funções: Você ou a plataforma reiniciam (ou param) a aplicação de funções aproximadamente na mesma altura em que uma invocação é solicitada. Uma reinicialização pode ocorrer devido a movimentos de instância de trabalho, atualizações de instância de trabalho ou dimensionamento.

Considerações de cancelamento

• Invocações em voo durante um evento de reinício podem ser tentadas novamente dependendo de como foram ativadas. Para mais informações, consulte a documentação de repetição.

• O host envia a invocação para o worker mesmo que o token de cancelamento seja cancelado antes de o host conseguir enviar o pedido de invocação ao worker.

• Se não quiseres que as invocações pré-canceladas sejam enviadas ao trabalhador, adiciona a SendCanceledInvocationsToWorker propriedade ao teu host.json ficheiro para desativar este comportamento.

  Este exemplo mostra um host.json ficheiro que utiliza esta propriedade:

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

• Definir SendCanceledInvocationsToWorker para false pode levar a uma FunctionInvocationCanceled exceção com o seguinte log:

  Foi solicitado o cancelamento. O pedido de invocação com id '{invocationId}' é cancelado e não será enviado ao trabalhador.

  Esta exceção ocorre quando o token de cancelamento é cancelado (como resultado de um dos eventos descritos anteriormente) antes do host enviar um pedido de invocação ao trabalhador. Esta exceção pode ser ignorada em segurança e é esperada quando SendCanceledInvocationsToWorker é false.

Enlaces

Defina ligações usando atributos em métodos, parâmetros e tipos de retorno. As associações podem fornecer dados como cadeias de caracteres, matrizes e tipos serializáveis, como objetos de classe antigos simples (POCOs). Para algumas extensões de vinculação, você também pode vincular a tipos específicos de serviço definidos em SDKs de serviço.

Para gatilhos HTTP, consulte a seção Gatilho HTTP.

Para um conjunto completo de amostras de referência que utilizam gatilhos e ligações com funções de processos de trabalhador isolados, consulte a amostra de referência das extensões de ligação.

Enlaces de entrada

Uma função pode ter zero ou mais ligações de entrada que passam dados para a função. Tal como nos triggers, defines ligações de entrada aplicando um atributo de ligação a um parâmetro de entrada. Quando a função é executada, o tempo de execução tenta obter dados especificados na ligação. Os dados solicitados dependem frequentemente da informação fornecida pelo gatilho através dos parâmetros de ligação.

Enlaces de saída

Para escrever numa ligação de saída, deve aplicar um atributo de ligação de saída ao método da função. Este atributo define como escrever no serviço vinculado. O valor de retorno do método é escrito na ligação de saída. Por exemplo, o exemplo a seguir grava um valor de cadeia de caracteres em uma fila de mensagens nomeada output-queue usando uma associação de saída:

[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;
}

Várias ligações de saída

Os dados gravados em uma ligação de saída são sempre o valor de retorno da função. Se você precisar gravar em mais de uma ligação de saída, deverá criar um tipo de retorno personalizado. Esse tipo de retorno deve ter o atributo de vinculação de saída aplicado a uma ou mais propriedades da classe. O exemplo seguinte é uma função ativada por HTTP que utiliza integração com ASP.NET Core e escreve tanto na resposta HTTP como numa associação de saída da fila.

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; }
    }
}

Quando utiliza tipos personalizados de retorno para múltiplas ligações de saída com integração do ASP.NET Core, deve adicionar o atributo [HttpResult] à propriedade que fornece o resultado. O HttpResult atributo está disponível ao usar o SDK 1.17.3-preview2 ou posterior , juntamente com a versão 3.2.0 ou posterior da extensão HTTP e a versão 1.3.0 ou posterior da extensão ASP.NET Core.

Tipos de SDK

Para alguns tipos de ligação específicas do serviço, pode fornecer dados de ligação utilizando tipos de SDKs e frameworks de serviço. Estes tipos oferecem capacidades além do que uma cadeia serializada ou um simples objeto CLR (POCO) pode proporcionar. Para usar os tipos mais recentes, atualize o seu projeto para usar versões mais recentes das dependências principais.

Ao testar tipos de SDK localmente em sua máquina, você também precisa usar as Ferramentas Principais do Azure Functions, versão 4.0.5000 ou posterior. Podes verificar a tua versão atual usando o func --version comando.

Cada extensão de ligação tem também o seu próprio requisito mínimo de versão, descrito nos artigos de referência da extensão. Estas extensões de binding suportam atualmente tipos de SDK:

Considerações para os tipos de SDK:

• Ao usar expressões de associação que dependem de dados de gatilho, os tipos de SDK para o gatilho em si não podem ser usados.
• Para cenários de saída onde podes usar um tipo de SDK, cria e trabalha diretamente com clientes SDK em vez de usar uma ligação de saída.
• O trigger do Azure Cosmos DB utiliza o feed de alterações do Azure Cosmos DB e expõe os itens do feed de alterações como tipos serializáveis em JSON. Como resultado, os tipos de SDK não são suportados para este trigger.

Acionador HTTP

Os gatilhos HTTP permitem que uma função seja invocada por uma solicitação HTTP. Pode usar duas abordagens diferentes:

• Um modelo de integração ASP.NET Core que usa conceitos familiares aos desenvolvedores do ASP.NET Core
• Um modelo interno, que não requer dependências extras e usa tipos personalizados para solicitações e respostas HTTP. Essa abordagem é mantida para compatibilidade com versões anteriores de aplicativos de trabalho isolados do .NET.

Integração ASP.NET Core

Esta secção mostra como trabalhar com os objetos HTTP de pedido e resposta subjacentes usando tipos do ASP.NET Core, incluindo HttpRequest, HttpResponse e IActionResult. Esse modelo não está disponível para aplicativos destinados ao .NET Framework, que devem usar o modelo interno.

Para habilitar a integração do ASP.NET Core para HTTP:

1. Adicione uma referência em seu projeto ao pacote Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore , versão 1.0.0 ou posterior.

2. Atualize seu projeto para usar estas versões específicas do pacote:

   • Microsoft.Azure.Functions.Worker.Sdk, versão 1.11.0. ou mais tarde
   • Microsoft.Azure.Functions.Worker, versão 1.16.0 ou posterior.

3. No arquivo Program.cs , atualize a configuração do construtor de hosts para chamar ConfigureFunctionsWebApplication(). Este método substitui ConfigureFunctionsWorkerDefaults() se usarias esse método de outra forma. O exemplo a seguir mostra uma configuração mínima sem outras personalizações:

   • IHostBuilder
   • IHostApplicationBuilder

   Nota

   Seu aplicativo deve fazer referência à versão 2.0.0 ou posterior do Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore para usar a integração do ASP.NET Core com IHostApplicationBuildero .

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

4. Atualize todas as funções acionadas por HTTP existentes para usar os tipos ASP.NET Core. Este exemplo mostra o padrão HttpRequest e um IActionResult usado para uma função simples "olá, mundo":

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

Serialização JSON com integração ASP.NET Core

ASP.NET Core tem a sua própria camada de serialização, e não é afetada pela personalização da configuração geral de serialização. Para personalizar o comportamento de serialização usado para seus gatilhos HTTP, você precisa incluir uma .AddMvc() chamada como parte do registro do serviço. O retornado IMvcBuilder pode ser usado para modificar as configurações de serialização JSON do ASP.NET Core.

Você pode continuar a usar HttpRequestData e HttpResponseData , ao usar ASP.NET integração, embora para a maioria dos aplicativos, seja melhor usar HttpRequest e IActionResult. O uso HttpRequestData/HttpResponseData não invoca a camada de serialização ASP.NET Core e, em vez disso, depende da configuração geral de serialização do trabalhador para o aplicativo. No entanto, quando a integração do ASP.NET Core estiver habilitada, talvez ainda seja necessário adicionar a configuração. O comportamento padrão do ASP.NET Core é não permitir E/S síncrona. Para usar um serializador personalizado que não suporta E/S assíncrona, como NewtonsoftJsonObjectSerializer, precisa ativar E/S síncrona para a sua aplicação configurando o arquivo KestrelServerOptions.

O exemplo a seguir mostra como configurar JSON.NET (Newtonsoft.Json) e o pacote NuGet Microsoft.AspNetCore.Mvc.NewtonsoftJson para serialização usando essa abordagem:

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

Modelo HTTP integrado

No modelo incorporado, o sistema traduz a mensagem de pedido HTTP recebida num objeto HttpRequestData que passa para a função. Este objeto fornece dados da solicitação, incluindo Headers, , , CookieseIdentities, opcionalmente, uma mensagem URLBody. Este objeto representa o pedido HTTP mas não está diretamente ligado ao ouvinte HTTP subjacente nem à mensagem recebida.

Da mesma forma, a função retorna um objeto HttpResponseData , que fornece dados usados para criar a resposta HTTP, incluindo a mensagem StatusCode, Headerse, opcionalmente, uma mensagem Body.

O exemplo a seguir demonstra o uso de HttpRequestData e 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;
}

Registo

Você pode gravar em logs usando uma ILogger<T> instância ou ILogger . Pode obter o logger através da injeção de dependência de um ILogger<T> ou de um 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}");
    }

}

Também podes passar o logger de um objeto FunctionContext para a tua função. Chame o método GetLogger<T> ou GetLogger , passando um valor de cadeia de caracteres que é o nome da categoria na qual os logs são gravados. A categoria é geralmente o nome da função específica a partir da qual os logs são gravados. Para mais informações sobre categorias, consulte o artigo de monitorização.

Use os métodos de e ILogger<T> para gravar vários níveis de ILogger log, como LogWarning ou LogError. Para mais informações sobre os níveis de registo, consulte o artigo de monitorização. Você pode personalizar os níveis de log para componentes adicionados ao seu código registrando filtros:

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

Como parte da configuração do seu aplicativo no Program.cs, você também pode definir o comportamento de como os erros são exibidos em seus logs. O comportamento padrão depende do tipo de construtor que você está usando.

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

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

host.Run();

Application Insights

Pode configurar a sua aplicação de processo isolado para enviar logs diretamente para o Application Insights. Esta configuração substitui o comportamento padrão de retransmitir registos através do host. A menos que estejas a usar o Aspire, configura a integração direta com o Application Insights porque isso dá-te controlo sobre como esses registos são emitidos.

A integração com o Application Insights não está ativada por defeito em todas as experiências de configuração. Alguns templates criam projetos de Functions com os pacotes necessários e o código de arranque comentados. Se pretender usar a integração com o Application Insights, descomente estas linhas no Program.cs e no ficheiro do .csproj do projeto. As instruções no restante desta seção também descrevem como habilitar a integração.

Se o seu projeto fizer parte de uma orquestração do Aspire, ele usa OpenTelemetry para monitorização. Não ative a integração direta do Application Insights em projetos Aspire. Em vez disso, configure o exportador do Azure Monitor OpenTelemetry como parte do projeto de padrões de serviço. Se o seu projeto Functions utiliza a integração com o Application Insights dentro de um contexto Aspire, a aplicação apresenta erros ao iniciar.

Instalar pacotes

Para gravar logs diretamente no Application Insights a partir do seu código, adicione referências a esses pacotes em seu projeto:

• Microsoft.Azure.Functions.Worker.ApplicationInsights, versão 1.0.0 ou posterior.
• Microsoft.ApplicationInsights.WorkerService.

Execute os seguintes comandos para adicionar estas referências ao seu projeto:

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

Configurar inicialização

Após instalar os pacotes, chame AddApplicationInsightsTelemetryWorkerService() e ConfigureFunctionsApplicationInsights() durante a configuração do serviço no seu Program.cs ficheiro, como mostrado no seguinte exemplo:

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

A chamada para ConfigureFunctionsApplicationInsights() adiciona um ITelemetryModule que ouve um ActivitySource definido por funções. Este módulo cria a telemetria de dependências necessária para suportar o rastreio distribuído. Para mais informações sobre AddApplicationInsightsTelemetryWorkerService() e como utilizá-lo, consulte Application Insights para aplicações de serviço de trabalhador.

Gerir níveis de registo

O resto do seu aplicativo continua a funcionar com ILogger e ILogger<T>. No entanto, por padrão, o SDK do Application Insights adiciona um filtro de log que instrui o registrador a capturar apenas avisos e logs mais severos. Pode configurar os níveis de registo no processo de trabalhador isolado de uma das seguintes formas:

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"
      }
    }
  }
}

Para mais informações sobre a configuração de registos, consulte Registos em .NET e Application Insights para aplicações de Worker Service.

Otimizações de desempenho

Esta secção descreve as opções que pode ativar e que melhoram o desempenho no arranque a frio.

Em geral, seu aplicativo deve usar as versões mais recentes de suas dependências principais. No mínimo, atualize o seu projeto da seguinte forma:

1. Atualize o Microsoft.Azure.Functions.Worker para a versão 1.19.0 ou posterior.
2. Atualize Microsoft.Azure.Functions.Worker.Sdk para a versão 1.16.4 ou posterior.
3. Adicione uma referência de estrutura ao , a menos que seu aplicativo tenha como destino o Microsoft.AspNetCore.App.NET Framework.

O trecho a seguir mostra essa configuração no contexto de um arquivo de projeto:

  <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>

Marcadores de Posição

Os espaços reservados são um recurso de plataforma que melhora o arranque a frio para aplicações destinadas ao .NET 6 ou posterior. Para usar esta otimização, deve ativar explicitamente os marcadores de posição seguindo estes passos:

1. Atualize a configuração do projeto para usar as versões de dependência mais recentes, conforme detalhado na seção anterior.

2. Defina a configuração da WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED aplicação para 1. Use este comando az functionapp config appsettings set

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

   Neste exemplo, substitua <groupName> pelo nome do grupo de recursos e substitua <appName> pelo nome do seu aplicativo de função.

3. Verifique se a netFrameworkVersion propriedade do aplicativo de função corresponde à estrutura de destino do seu projeto, que deve ser .NET 6 ou posterior. Use o seguinte comando az functionapp config set:

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

   Neste exemplo, substitua <framework> também pela cadeia de caracteres de versão apropriada, como v8.0, de acordo com sua versão .NET de destino.

4. Certifique-se de que a sua aplicação de funções está configurada para usar um processo de 64 bits. Use este comando az functionapp config set :

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

Executor otimizado

O executor de função é um componente da plataforma que faz com que as invocações sejam executadas. Uma versão otimizada desse componente é habilitada por padrão a partir da versão 1.16.2 do SDK. Nenhuma outra configuração é necessária.

ReadyToRun

Você pode compilar seu aplicativo de função como binários ReadyToRun. O ReadyToRun é uma forma de compilação antecipada que pode melhorar o desempenho de inicialização para ajudar a reduzir o efeito de partidas a frio ao executar em um plano de consumo. O ReadyToRun está disponível no .NET 6 e versões posteriores e requer a versão 4.0 ou posterior do tempo de execução do Azure Functions.

ReadyToRun requer que você crie o projeto em relação à arquitetura de tempo de execução do aplicativo de hospedagem. Quando estas arquiteturas não estão alinhadas, a sua aplicação encontra um erro no arranque. Selecione seu identificador de tempo de execução nesta tabela:

1 Apenas as aplicações de 64 bits são elegíveis para outras otimizações de desempenho.

Para verificar se a sua aplicação Windows é de 32 ou 64 bits, execute o seguinte comando CLI, substituindo <group_name> pelo nome do seu grupo de recursos e <app_name> pelo nome da sua aplicação. Uma saída de "true" indica que o aplicativo é de 32 bits e "false" indica 64 bits.

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

Você pode alterar seu aplicativo para 64 bits com o seguinte comando, usando as mesmas substituições:

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

Para compilar seu projeto como ReadyToRun, atualize seu arquivo de projeto adicionando os <PublishReadyToRun> elementos e <RuntimeIdentifier> . O exemplo a seguir mostra uma configuração para publicação em um aplicativo de função de 64 bits do Windows.

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

Se não quiseres definir as <RuntimeIdentifier> como parte do ficheiro do projeto, também podes configurar esta definição como parte do próprio gesto de publicação. Por exemplo, numa aplicação de funções Windows de 64 bits, o comando .NET CLI é:

dotnet publish --runtime win-x64

No Visual Studio, defina a opção Target Runtime no perfil de publicação para o identificador correto de runtime. Quando definido como o valor padrão de Portable, ReadyToRun não é usado.

Implementar para as Funções do Azure

Quando você implanta seu projeto de código de função no Azure, ele deve ser executado em um aplicativo de função ou em um contêiner Linux. Tens de criar a aplicação de funções e outros recursos necessários do Azure antes de implementares o teu código.

Você também pode implantar seu aplicativo de função em um contêiner Linux. Para obter mais informações, consulte Trabalhando com contêineres e Azure Functions.

Criar recursos do Azure

Pode criar a sua aplicação de funções e outros recursos necessários no Azure usando um destes métodos:

• Visual Studio: Visual Studio pode criar recursos para você durante o processo de publicação de código.
• Visual Studio Code: o Visual Studio Code pode se conectar à sua assinatura, criar os recursos necessários para seu aplicativo e, em seguida, publicar seu código.
• Azure CLI: Use a CLI Azure para criar os recursos necessários no Azure.
• Azure PowerShell: Use o Azure PowerShell para criar os recursos necessários no Azure.
• Modelos de implementação: Use modelos ARM e ficheiros Bicep para automatizar a implementação dos recursos necessários no Azure. Certifique-se de que o seu modelo inclui todas as definições necessárias.
• Portal Azure: Crie os recursos necessários no portal Azure.

Publicar a aplicação

Depois de criar a sua aplicação de funções e outros recursos necessários no Azure, implemente o projeto de código no Azure usando um destes métodos:

• Visual Studio: Implantação manual simples durante o desenvolvimento.
• Visual Studio Code: Implantação manual simples durante o desenvolvimento.
• Ferramentas principais do Azure Functions: implante o arquivo de projeto a partir da linha de comando.
• Implantação contínua: Útil para manutenção contínua, freqüentemente para um slot de preparação.
• Modelos de implantação: você pode usar modelos ARM ou arquivos Bicep para automatizar implantações de pacotes.

Para obter mais informações, consulte Tecnologias de implantação no Azure Functions.

Carga útil de implantação

Muitos dos métodos de implementação usam um arquivo zip. Se criar o arquivo zip por si próprio, ele deve seguir a estrutura descrita nesta secção. Se não acontecer, a sua aplicação pode apresentar erros no arranque.

A carga útil de implantação deve corresponder à saída de um dotnet publish comando, embora sem a pasta pai que a inclui. O arquivo zip deve ser feito a partir dos seguintes arquivos:

• .azurefunctions/
• extensions.json
• functions.metadata
• host.json
• worker.config.json
• Seu executável de projeto (um aplicativo de console)
• Outros arquivos e diretórios de suporte são correspondentes a esse executável

O processo de compilação gera estes ficheiros, e não deves editá-los diretamente.

Ao preparar um arquivo zip para implementação, comprima apenas o conteúdo do diretório de saída, e não o diretório envolvente. Quando o arquivo é extraído para o diretório de trabalho atual, os ficheiros listados anteriormente precisam de ser imediatamente visíveis.

Requisitos de implantação

Para executar funções .NET no modelo de trabalhador isolado no Azure, é necessário cumprir alguns requisitos. Os requisitos dependem do sistema operativo:

Quando você cria seu aplicativo de função no Azure usando os métodos na seção anterior, essas configurações necessárias são adicionadas para você. Ao criar esses recursos usando modelos ARM ou arquivos Bicep para automação, certifique-se de defini-los no modelo.

Aspire

Aspire é uma stack estruturada que simplifica o desenvolvimento de aplicações distribuídas na nuvem. Pode recrutar projetos de modelo de trabalhador isolados nas orquestrações do Aspire 13. Consulte Azure Functions com o Aspire para obter mais informações.

Depuração

Ao executar localmente usando o Visual Studio ou Visual Studio Code, você pode depurar seu projeto de trabalho isolado do .NET normalmente. No entanto, há dois cenários de depuração que não funcionam como esperado.

Depuração remota usando o Visual Studio

Como seu aplicativo de processo de trabalho isolado é executado fora do tempo de execução do Functions, você precisa anexar o depurador remoto a um processo separado. Para saber mais sobre depuração usando o Visual Studio, consulte Depuração remota.

Depuração ao direcionar o .NET Framework

Se seu projeto isolado tem como alvo o .NET Framework 4.8, você precisa executar etapas manuais para habilitar a depuração. Essas etapas não são necessárias se estiver usando outra estrutura de destino.

Seu aplicativo deve começar com uma chamada para FunctionsDebugger.Enable(); como sua primeira operação. Isso ocorre no método antes de Main() inicializar um HostBuilder. Seu Program.cs arquivo deve ser semelhante a este:

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

Em seguida, você precisa anexar manualmente ao processo usando um depurador do .NET Framework. O Visual Studio ainda não faz isso automaticamente para aplicativos .NET Framework de processo de trabalho isolados, e a operação "Iniciar depuração" deve ser evitada.

No diretório do projeto (ou no diretório de saída da compilação), execute:

func host start --dotnet-isolated-debug

Isso inicia o trabalhador e o processo para com a seguinte mensagem:

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

Onde <process id> é a ID do seu processo de trabalho. Agora você pode usar o Visual Studio para anexar manualmente ao processo. Para obter instruções sobre esta operação, consulte Como anexar a um processo em execução.

Depois que o depurador for anexado, a execução do processo será retomada e você poderá depurar.

Visualizar versões do .NET

Antes de uma versão geralmente disponível, uma versão do .NET pode ser lançada em um estado de visualização ou Go-live . Consulte a Política de Suporte Oficial do .NET para obter detalhes sobre esses estados.

Embora seja possível direcionar uma determinada versão de um projeto local do Functions, os aplicativos de função hospedados no Azure podem não ter essa versão disponível. O Azure Functions só pode ser usado com versões de visualização ou Go-live indicadas nesta seção.

O Azure Functions atualmente não funciona com nenhuma versão "Preview" ou "Go-live" de .NET. Consulte Versões suportadas para obter uma lista das versões geralmente disponíveis que você pode usar.

Usando um SDK .NET de visualização

Para usar o Azure Functions com uma versão de visualização do .NET, você precisa atualizar seu projeto da seguinte forma:

1. Instalando a versão relevante do SDK do .NET em seu desenvolvimento
2. Alterar a TargetFramework definição no ficheiro .csproj

Ao implantar em seu aplicativo de função no Azure, você também precisa garantir que a estrutura seja disponibilizada para o aplicativo. Durante o período de visualização, algumas ferramentas e experiências podem não apresentar a nova versão de visualização como uma opção. Se não vir a versão de pré-visualização incluída no portal do Azure, por exemplo, pode utilizar a API REST, os ficheiros Bicep ou a CLI do Azure para configurar a versão manualmente.

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>"

Considerações sobre o uso de versões de visualização do .NET

Tenha estas considerações em mente ao usar o Functions com versões de visualização do .NET:

• Ao criar suas funções no Visual Studio, você deve usar o Visual Studio Insiders, que dá suporte à criação de projetos do Azure Functions com SDKs de visualização do .NET.

• Certifique-se de que tem as ferramentas e modelos mais recentes do Functions. Para atualizar suas ferramentas:

  1. Navegue atéOpções de Ferramentas>, escolha Azure Functions em Projetos e Soluções>Mais Configurações.
  2. Selecione Verificar se há atualizações e instale as atualizações conforme solicitado.

• Durante um período de visualização, seu ambiente de desenvolvimento pode ter uma versão mais recente do .NET preview do que o serviço hospedado. Isso pode fazer com que seu aplicativo de função falhe quando implantado. Para resolver isso, você pode especificar a versão do SDK a ser usada no global.json.

  1. Execute o comando e anote a versão de visualização que você está usando atualmente durante o dotnet --list-sdks desenvolvimento local.
  2. Execute o dotnet new globaljson --sdk-version <SDK_VERSION> --force comando, onde <SDK_VERSION> é a versão que você está usando localmente. Por exemplo, dotnet new globaljson --sdk-version dotnet-sdk-10.0.100-preview.5.25277.114 --force faz com que o sistema use o SDK do .NET 10 Preview 5 ao criar seu projeto.

Próximos passos