Partilhar via

Migrar aplicativos .NET do modelo em processo para o modelo de trabalho isolado

  • Artigo

Importante

O suporte para o modelo em processo terminará em 10 de novembro de 2026. É altamente recomendável que você migre seus aplicativos para o modelo de trabalho isolado seguindo as instruções neste artigo.

Este artigo orienta você pelo processo de migração segura do aplicativo de função .NET do modelo em processo para o modelo de trabalho isolado. Para saber mais sobre as diferenças de alto nível entre esses modelos, consulte a comparação do modo de execução.

Este guia pressupõe que seu aplicativo esteja sendo executado na versão 4.x do tempo de execução do Functions. Caso contrário, você deve seguir os guias para atualizar sua versão do host:

Esses guias de migração de versão de host também ajudam você a migrar para o modelo de trabalho isolado à medida que você trabalha neles.

Identificar aplicativos de função a serem migrados

Use o seguinte script do Azure PowerShell para gerar uma lista de aplicativos de função em sua assinatura que atualmente usam o modelo em processo.

O script usa a assinatura que o Azure PowerShell está configurado para usar no momento. Você pode alterar a assinatura executando primeiro Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' e substituindo <YOUR SUBSCRIPTION ID> pelo ID da assinatura que deseja avaliar.

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     if ($App.Runtime -eq 'dotnet')
     {
          $AppInfo.Add($App.Name, $App.Runtime)
     }
}

$AppInfo

Escolha sua versão .NET de destino

Na versão 4.x do tempo de execução do Functions, seu aplicativo de função .NET tem como alvo o .NET 6 ou .NET 8 ao usar o modelo em processo.

Ao migrar seu aplicativo de função, você tem a oportunidade de escolher a versão de destino do .NET. Você pode atualizar seu projeto C# para uma das seguintes versões do .NET que são suportadas pelo Functions versão 4.x:

Versão .NET Tipo de versão da Política de Suporte Oficial do .NET Funções modelode processo 1,2
.NET 9 STS (fim do suporte em 12 de maio de 2026) Modelo de trabalhador isolado
.NET 8 LTS (fim do suporte em 10 de novembro de 2026) Modelo de trabalhador isolado,
Modeloem processo 2
.NET Framework 4.8 Ver política Modelo de trabalhador isolado

1 O modelo de trabalho isolado suporta as versões LTS (Long Term Support) e STS (Standard Term Support) do .NET, bem como do .NET Framework. O modelo em processo suporta apenas versões LTS do .NET, terminando com .NET 8. Para obter uma comparação completa de recursos e funcionalidades entre os dois modelos, consulte Diferenças entre o processo de trabalho em processo e o processo de trabalho isolado .NET Azure Functions.

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

Gorjeta

Recomendamos atualizar para o .NET 8 no modelo de trabalho isolado. Isso fornece um caminho de migração rápida para a versão totalmente lançada com a janela de suporte mais longa do .NET.

Este guia não apresenta exemplos específicos para o .NET 9. Se você precisar direcionar essa versão, você pode adaptar os exemplos do .NET 8.

Prepare para a migração

Se ainda não o fez, identifique a lista de aplicativos que precisam ser migrados em sua Assinatura do Azure atual usando o Azure PowerShell.

Antes de migrar um aplicativo para o modelo de trabalho isolado, você deve revisar cuidadosamente o conteúdo deste guia. Você também deve se familiarizar com as características do modelo de trabalhador isolado e as diferenças entre os dois modelos.

Para migrar o aplicativo, você irá:

  1. Migre seu projeto local para o modelo de trabalho isolado seguindo as etapas em Migrar seu projeto local.
  2. Depois de migrar seu projeto, teste totalmente o aplicativo localmente usando a versão 4.x das Ferramentas Principais do Azure Functions.
  3. Atualize seu aplicativo de função no Azure para o modelo isolado.

Migre seu projeto local

A seção descreve as várias alterações que você precisa fazer em seu projeto local para movê-lo para o modelo de trabalhador isolado. Algumas das etapas mudam com base na sua versão de destino do .NET. Use as guias para selecionar as instruções que correspondem à versão desejada. Essas etapas pressupõem um projeto C# local e, se seu aplicativo estiver usando script C# (.csx arquivos), você deverá converter para o modelo de projeto antes de continuar.

Gorjeta

Se você estiver mudando para uma versão LTS ou STS do .NET, o Assistente de Atualização do .NET pode ser usado para fazer automaticamente muitas das alterações mencionadas nas seções a seguir.

Primeiro, converta o arquivo de projeto e atualize suas dependências. Ao fazê-lo, você verá erros de compilação para o projeto. Nas etapas subsequentes, você fará as alterações correspondentes para remover esses erros.

Ficheiro de projeto

O exemplo a seguir é um arquivo de projeto que usa o .csproj .NET 8 na versão 4.x:

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

Use um dos procedimentos a seguir para atualizar esse arquivo XML para ser executado no modelo de trabalho isolado:

Essas etapas pressupõem um projeto C# local e, se seu aplicativo estiver usando script C# (.csx arquivos), você deverá converter para o modelo de projeto antes de continuar.

As seguintes alterações são necessárias no arquivo de .csproj projeto XML:

  1. Defina o valor de PropertyGroup.TargetFramework para net8.0.

  2. Defina o valor de PropertyGroup.AzureFunctionsVersion para v4.

  3. Adicione o seguinte OutputType elemento ao PropertyGroup:

    <OutputType>Exe</OutputType>

  4. No .ItemGroupPackageReference substitua a referência do pacote pelas Microsoft.NET.Sdk.Functions seguintes referências:

      <FrameworkReference Include="Microsoft.AspNetCore.App" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
  <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />

    Anote quaisquer referências a outros pacotes nos Microsoft.Azure.WebJobs.* namespaces. Você substituirá esses pacotes em uma etapa posterior.

  5. Aditar o seguinte novo ItemGroup:

    <ItemGroup>
  <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
</ItemGroup>

Depois de fazer essas alterações, seu projeto atualizado deve se parecer com o exemplo a seguir:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <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.17.2" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
    <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
    <!-- Other packages may also be in this list -->
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
  <ItemGroup>
    <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
  </ItemGroup>
</Project>

Alterar a estrutura de destino do seu projeto também pode exigir alterações em partes da sua cadeia de ferramentas, fora do código do projeto. Por exemplo, no VS Code, talvez seja necessário atualizar a configuração da azureFunctions.deploySubpath extensão por meio das configurações do usuário ou do .vscode/settings.json arquivo do seu projeto. Verifique se há dependências na versão da estrutura que possam existir fora do código do projeto, como parte das etapas de compilação ou de um pipeline de CI/CD.

Referências de pacotes

Ao migrar para o modelo de trabalho isolado, você precisa alterar os pacotes aos quais seu aplicativo faz referência.

Se ainda não o fez, atualize o seu projeto para fazer referência às versões estáveis mais recentes de:

Dependendo dos gatilhos e associações que seu aplicativo usa, talvez seja necessário fazer referência a um conjunto diferente de pacotes. A tabela a seguir mostra as substituições para algumas das extensões mais usadas:

Cenário Alterações nas referências do pacote
Acionador de temporizador Adicionar
Microsoft.Azure.Functions.Worker.Extensions.Timer
Enlaces de armazenamento Replace
Microsoft.Azure.WebJobs.Extensions.Storage
com o
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues e
Microsoft.Azure.Functions.Worker.Extensions.Tables
Enlaces de blobs Substitua as referências a
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
com a última versão do
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Enlaces de filas Substitua as referências a
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
com a última versão do
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Enlaces de tabelas Substitua as referências a
Microsoft.Azure.WebJobs.Extensions.Tables
com a última versão do
Microsoft.Azure.Functions.Worker.Extensions.Tables
Enlaces do Cosmos DB Substitua as referências a
Microsoft.Azure.WebJobs.Extensions.CosmosDB
e/ou
Microsoft.Azure.WebJobs.Extensions.DocumentDB
com a última versão do
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Enlaces do Service Bus Substitua as referências a
Microsoft.Azure.WebJobs.Extensions.ServiceBus
com a última versão do
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Ligações de Hubs de Eventos Substitua as referências a
Microsoft.Azure.WebJobs.Extensions.EventHubs
com a última versão do
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Ligações de grade de eventos Substitua as referências a
Microsoft.Azure.WebJobs.Extensions.EventGrid
com a última versão do
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
Enlaces do SignalR Service Substitua as referências a
Microsoft.Azure.WebJobs.Extensions.SignalRService
com a última versão do
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Funções Duráveis Substitua as referências a
Microsoft.Azure.WebJobs.Extensions.DurableTask
com a última versão do
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Funções Duráveis
(Provedor de armazenamento SQL)		 Substitua as referências a
Microsoft.DurableTask.SqlServer.AzureFunctions
com a última versão do
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Funções Duráveis
(Provedor de armazenamento Netherite)		 Substitua as referências a
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
com a última versão do
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
Enlaces do SendGrid Substitua as referências a
Microsoft.Azure.WebJobs.Extensions.SendGrid
com a última versão do
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Ligações Kafka Substitua as referências a
Microsoft.Azure.WebJobs.Extensions.Kafka
com a última versão do
Microsoft.Azure.Functions.Worker.Extensions.Kafka
Ligações RabbitMQ Substitua as referências a
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
com a última versão do
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
Injeção de dependência
e configuração de inicialização		 Remover referências a
Microsoft.Azure.Functions.Extensions
(O modelo de trabalho isolado fornece essa funcionalidade por padrão.)

Consulte Ligações suportadas para obter uma lista completa de extensões a serem consideradas e consulte a documentação de cada extensão para obter instruções de instalação completas para o modelo de processo isolado. Certifique-se de instalar a versão estável mais recente de todos os pacotes que você está segmentando.

Gorjeta

Quaisquer alterações nas versões de extensão durante esse processo podem exigir que você atualize seu host.json arquivo também. Certifique-se de ler a documentação de cada extensão que você usa. Por exemplo, a extensão do Service Bus tem alterações significativas na estrutura entre as versões 4.x e 5.x. Para obter mais informações, consulte Associações do Barramento de Serviço do Azure para o Azure Functions.

Seu aplicativo de modelo de trabalho isolado não deve fazer referência a nenhum pacote nos Microsoft.Azure.WebJobs.* namespaces ou Microsoft.Azure.Functions.Extensions. Se você tiver quaisquer referências restantes a estes, eles devem ser removidos.

Gorjeta

Seu aplicativo também pode depender dos tipos de SDK do Azure, como parte de seus gatilhos e associações ou como uma dependência autônoma. Você deve aproveitar esta oportunidade para atualizá-los também. As versões mais recentes das extensões do Functions funcionam com as versões mais recentes do SDK do Azure para .NET, quase todos os pacotes para os quais são o formulário Azure.*.

Program.cs arquivo

Ao migrar para execução em um processo de trabalho isolado, você deve adicionar um Program.cs arquivo ao seu projeto com o seguinte conteúdo:

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

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

host.Run();

Este exemplo inclui a integração ASP.NET Core para melhorar o desempenho e fornecer um modelo de programação familiar quando seu aplicativo usa gatilhos HTTP. Se você não pretende usar gatilhos HTTP, você pode substituir a chamada para ConfigureFunctionsWebApplication por uma chamada para ConfigureFunctionsWorkerDefaults. Se você fizer isso, você pode remover a referência a Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore do seu arquivo de projeto. No entanto, para o melhor desempenho, mesmo para funções com outros tipos de gatilho, você deve manter o FrameworkReference ASP.NET Core.

O Program.cs arquivo substituirá qualquer arquivo que tenha o FunctionsStartup atributo, que normalmente é um Startup.cs arquivo. Em locais onde seu FunctionsStartup código faria referência IFunctionsHostBuilder.Services, você pode, em vez disso, adicionar instruções dentro do .ConfigureServices() método do HostBuilder em seu Program.cs. Para saber mais sobre como trabalhar com Program.cso , consulte Inicialização e configuração no guia de modelo de trabalhador isolado.

Os exemplos padrão Program.cs acima incluem a configuração da integração do Application Insights para o modelo de trabalho isolado. No , Program.csvocê também deve configurar qualquer filtragem de log que deve ser aplicada a logs provenientes do código em seu projeto. No modelo de trabalho isolado, o arquivo controla host.json apenas os eventos emitidos pelo tempo de execução do host Functions. Se você não configurar regras de filtragem no Program.cs, poderá ver diferenças nos níveis de log presentes para várias categorias em sua telemetria.

Embora você possa registrar fontes de configuração personalizadas como parte do HostBuilder, observe que elas também se aplicam apenas ao código em seu projeto. A configuração de acionamento e vinculação também é necessária para a plataforma, e isso deve ser fornecido por meio das configurações do aplicativo, referências do Cofre da Chave ou recursos de referências de Configuração do Aplicativo.

Depois de mover tudo de qualquer existente FunctionsStartup para o Program.cs arquivo, você pode excluir o FunctionsStartup atributo e a classe à qual ele foi aplicado.

Alterações na assinatura da função

Alguns tipos de chave mudam entre o modelo em processo e o modelo de trabalhador isolado. Muitos deles estão relacionados aos atributos, parâmetros e tipos de retorno que compõem a assinatura da função. Para cada uma das suas funções, você deve fazer alterações em:

  • O atributo function (que também define o nome da função)
  • Como a função obtém um ILogger/ILogger<T>
  • Atributos e parâmetros de acionamento e vinculação

O restante desta seção orienta você por cada uma dessas etapas.

Atributos de função

O Function atributo no modelo de trabalho isolado substitui o FunctionName atributo. O novo atributo tem a mesma assinatura, e a única diferença está no nome. Portanto, você pode apenas executar uma substituição de cadeia de caracteres em todo o projeto.

Registo

No modelo em processo, você pode incluir um parâmetro opcional ILogger para sua função ou pode usar a injeção de dependência para obter um ILogger<T>arquivo . Se seu aplicativo já usou a injeção de dependência, os mesmos mecanismos funcionam no modelo de trabalhador isolado.

No entanto, para quaisquer funções que dependiam do ILogger parâmetro de método, você precisa fazer uma alteração. Recomenda-se que utilize a injeção de dependência para obter um ILogger<T>ficheiro . Use as seguintes etapas para migrar o mecanismo de log da função:

  1. Na sua classe de função, adicione uma private readonly ILogger<MyFunction> _logger; propriedade, substituindo MyFunction pelo nome da sua classe de função.

  2. Crie um construtor para sua classe de função que recebe o ILogger<T> parâmetro as:

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

    Substitua ambas as instâncias do trecho de MyFunction código anterior pelo nome da sua classe de função.

  3. Para registrar operações em seu código de função, substitua as ILogger referências ao parâmetro por _logger.

  4. Remova o ILogger parâmetro da assinatura da função.

Para saber mais, consulte Registro em log no modelo de trabalhador isolado.

Alterações de gatilho e vinculação

Quando você alterou as referências do pacote em uma etapa anterior, introduziu erros para seus gatilhos e ligações que agora serão corrigidos:

  1. Remova todas as using Microsoft.Azure.WebJobs; instruções.

  2. Adicione uma using Microsoft.Azure.Functions.Worker; instrução.

  3. Para cada atributo de vinculação, altere o nome do atributo conforme especificado em sua documentação de referência, que você pode encontrar no índice de ligações suportadas. Em geral, os nomes dos atributos mudam da seguinte maneira:

    • Os gatilhos normalmente permanecem nomeados da mesma maneira. Por exemplo, QueueTrigger é o nome do atributo para ambos os modelos.
    • As ligações de entrada normalmente precisam de "Entrada" adicionada ao seu nome. Por exemplo, se você usasse o CosmosDB atributo de vinculação de entrada no modelo em processo, o atributo agora seria CosmosDBInput.
    • As ligações de saída normalmente precisam de "Saída" adicionada ao seu nome. Por exemplo, se você usasse o Queue atributo de vinculação de saída no modelo em processo, esse atributo agora seria QueueOutput.

  4. Atualize os parâmetros de atributo para refletir a versão do modelo de trabalho isolado, conforme especificado na documentação de referência da associação.

    Por exemplo, no modelo em processo, uma ligação de saída de blob é representada por um [Blob(...)] atributo que inclui uma Access propriedade. No modelo de trabalhador isolado, o atributo de saída de blob seria [BlobOutput(...)]. A associação não requer mais a propriedade, para que o Access parâmetro possa ser removido. Assim [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] se tornaria [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

  5. Mova as ligações de saída para fora da lista de parâmetros da função. Se você tiver apenas uma ligação de saída, poderá aplicá-la ao tipo de retorno da função. Se você tiver várias saídas, crie uma nova classe com propriedades para cada saída e aplique os atributos a essas propriedades. Para saber mais, consulte Várias ligações de saída.

  6. Consulte a documentação de referência de cada ligação para saber os tipos aos quais ela permite vincular. Em alguns casos, pode ser necessário alterar o tipo. Para ligações de saída, se a versão do modelo em processo usou um IAsyncCollector<T>, você pode substituí-lo por ligação a uma matriz do tipo de destino: T[]. Você também pode considerar substituir a ligação de saída por um objeto cliente para o serviço que ela representa, seja como o tipo de associação para uma ligação de entrada, se disponível, ou injetando um cliente você mesmo.

  7. Se a sua função incluir um IBinder parâmetro, remova-o. Substitua a funcionalidade por um objeto cliente para o serviço que ele representa, seja como o tipo de ligação para uma associação de entrada, se disponível, ou injetando um cliente por conta própria.

  8. Atualize o código da função para trabalhar com quaisquer novos tipos.

local.settings.json arquivo

O arquivo local.settings.json só é usado quando executado localmente. Para obter informações, consulte Arquivo de configurações locais.

Ao migrar da execução em processo para a execução em um processo de trabalho isolado, você precisa alterar o FUNCTIONS_WORKER_RUNTIME valor para "dotnet-isolated". Certifique-se de que o ficheiro local.settings.json tem pelo menos os seguintes elementos:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

O valor que você tem para 'AzureWebJobsStorage'' pode ser diferente. Não é necessário alterar seu valor como parte da migração.

host.json arquivo

Não são necessárias alterações ao seu host.json ficheiro. No entanto, se a configuração do Application Insights neste arquivo for do seu projeto de modelo em processo, convém fazer alterações adicionais no arquivo Program.cs . O host.json arquivo controla apenas o log do tempo de execução do host do Functions e, no modelo de trabalho isolado, alguns desses logs vêm diretamente do seu aplicativo, oferecendo mais controle. Consulte Gerenciando níveis de log no modelo de trabalho isolado para obter detalhes sobre como filtrar esses logs.

Outras alterações de código

Esta seção destaca outras alterações de código a serem consideradas ao trabalhar na migração. Essas alterações não são necessárias para todos os aplicativos, mas você deve avaliar se alguma é relevante para seus cenários.

Serialização JSON

Por padrão, o modelo de trabalho isolado usa System.Text.Json para serialização JSON. Para personalizar as opções do serializador ou alternar para JSON.NET (Newtonsoft.Json), consulte estas instruções.

Níveis de log e filtragem do Application Insights

Os logs podem ser enviados para o Application Insights a partir do tempo de execução do host do Functions e do código em seu projeto. O host.json permite que você configure regras para registro em log do host, mas para controlar logs provenientes do seu código, você precisará configurar regras de filtragem como parte do seu Program.cs. Consulte Gerenciando níveis de log no modelo de trabalho isolado para obter detalhes sobre como filtrar esses logs.

Exemplo de migrações de função

Exemplo de gatilho HTTP

Um gatilho HTTP para o modelo em processo pode se parecer com o exemplo a seguir:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public static class HttpTriggerCSharp
    {
        [FunctionName("HttpTriggerCSharp")]
        public static IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

Um gatilho HTTP para a versão migrada pode se parecer com o exemplo a seguir:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public class HttpTriggerCSharp
    {
        private readonly ILogger<HttpTriggerCSharp> _logger;

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

        [Function("HttpTriggerCSharp")]
        public IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

Atualizar seu aplicativo de função no Azure

Atualizar seu aplicativo de função para o modelo isolado envolve duas alterações que devem ser concluídas juntas, porque se você concluir apenas uma, o aplicativo estará em um estado de erro. Ambas as alterações também fazem com que o processo do aplicativo seja reiniciado. Por esses motivos, você deve executar a atualização usando um slot de preparo. Os slots de preparo ajudam a minimizar o tempo de inatividade do seu aplicativo e permitem que você teste e verifique seu código migrado com sua configuração atualizada no Azure. Em seguida, você pode implantar seu aplicativo totalmente migrado para o slot de produção por meio de uma operação de troca.

Importante

Quando a carga útil implantada de um aplicativo não corresponde ao tempo de execução configurado, ela estará em um estado de erro. Durante o processo de migração, você colocará o aplicativo nesse estado, idealmente apenas temporariamente. Os slots de implantação ajudam a mitigar o impacto disso, porque o estado de erro será resolvido em seu ambiente de preparo (não produção) antes que as alterações sejam aplicadas como uma única atualização ao seu ambiente de produção. Os slots também se defendem contra quaisquer erros e permitem que você detete quaisquer outros problemas antes de chegar à produção.

Durante o processo, você ainda pode ver erros nos logs provenientes do seu slot de preparo (não produção). Isto é esperado, embora estes devam desaparecer à medida que avança com os passos. Antes de executar a operação de troca de slot, você deve confirmar se esses erros param de ser gerados e se seu aplicativo está funcionando conforme o esperado.

Use as seguintes etapas para usar slots de implantação para atualizar seu aplicativo de função para o modelo de trabalho isolado:

  1. Crie um slot de implantação, se ainda não o fez. Você também pode querer se familiarizar com o processo de troca de slot e garantir que você possa fazer atualizações para o aplicativo existente com o mínimo de interrupção.

  2. Altere a configuração do slot de preparo (não produção) para usar o modelo de trabalho isolado definindo a configuração do FUNCTIONS_WORKER_RUNTIME aplicativo como dotnet-isolated. FUNCTIONS_WORKER_RUNTIMEnão deve ser marcado como uma "definição de ranhura".

    Se você também estiver direcionando uma versão diferente do .NET como parte de sua atualização, você também deve alterar a configuração da pilha. Para fazer isso, consulte as instruções para atualizar a configuração da pilha para o modelo de trabalho isolado. Você usará as mesmas instruções para quaisquer futuras atualizações de versão do .NET que fizer.

    Se você tiver algum provisionamento de infraestrutura automatizado, como um pipeline de CI/CD, certifique-se de que as automações também sejam atualizadas para dotnet-isolated manter FUNCTIONS_WORKER_RUNTIME definido e direcionar a versão correta do .NET.

  3. Publique seu projeto migrado no slot de preparo (não produção) do seu aplicativo de função.

    Se você usar o Visual Studio para publicar um projeto de modelo de trabalho isolado em um aplicativo ou slot existente que usa o modelo em processo, ele também poderá concluir a etapa anterior para você ao mesmo tempo. Se você não concluiu a etapa anterior, o Visual Studio solicitará que você atualize o aplicativo de função durante a implantação. Visual Studio apresenta isso como uma única operação, mas essas ainda são duas operações separadas. Você ainda pode ver erros em seus logs do slot de preparo (não produção) durante o estado provisório.

  4. Confirme se seu aplicativo está funcionando conforme o esperado dentro do slot de preparo (não produção).

  5. Execute uma operação de troca de slot. Isso aplica as alterações feitas no slot de preparo (não produção) ao slot de produção. Uma troca de slot acontece como uma única atualização, o que evita a introdução do estado de erro provisório em seu ambiente de produção.

  6. Confirme se seu aplicativo está funcionando conforme o esperado dentro do slot de produção.

Depois de concluir essas etapas, a migração será concluída e seu aplicativo será executado no modelo isolado. Parabéns! Repita as etapas deste guia conforme necessário para quaisquer outros aplicativos que precisem de migração.

Próximos passos

Saiba mais sobre o modelo de trabalhador isolado