Compartilhar via

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

  • Artigo

Importante

O suporte terminará para o modelo em processo em 10 de novembro de 2026. É altamente recomendável migrar 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ções .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, confira a comparação entre modos de execução.

Este guia pressupõe que seu aplicativo esteja em execução na versão 4.x do runtime do Functions. Caso contrário, siga os guias para atualizar a versão do host:

Esses guias de migração de versão do host também ajudam você a migrar para o modelo de trabalho isolado enquanto você trabalha com eles.

Identificar aplicativos de funções a serem migrados

Use o seguinte script do Azure PowerShell para gerar uma lista de aplicativos de funções 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> pela 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

Escolher a versão do .NET de destino

Na versão 4.x do runtime do Functions, seu aplicativo de funções .NET tem como destino o .NET 6 ao usar o modelo em processo.

Ao migrar seu aplicativo de funções, 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 podem ser executadas na versão 4.x do Functions:

Versão do .NET Tipo de versão da política de suporte oficial do .NET Modelo de processo de funções1,2
.NET 9 Versão prévia3 Modelo de trabalho isolado
.NET 8 LTS (fim do suporte em 10 de novembro de 2026) Modelo de trabalho isolado,
Modelo em processo2
.NET 6 LTS (fim do suporte 12 de novembro de 2024) Modelo de trabalho isolado,
Modelo em processo2
.NET Framework 4.8 Consultar política Modelo de trabalho isolado

1 O modelo de trabalho isolado dá suporte às versões LTS (suporte de longo prazo) e STS (suporte de curto prazo) do .NET, bem como .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, confira Diferenças entre o processo de trabalho isolado e em processo do Azure Functions no .NET.

2 O suporte para o modelo em processo termina em 10 de novembro de 2026. Para obter mais informações, confira este comunicado de suporte. Para obter suporte completo contínuo, você deve migrar seus aplicativos para o modelo de trabalho isolado.

3Confira Pré-visualizar as versões do .NET no modelo de trabalho isolado para obter detalhes sobre suporte, restrições atuais e instruções para uso da versão prévia.

Dica

É recomendável atualizar para o .NET 8 no modelo de trabalho isolado. Isso proporciona um caminho de migração rápido para a versão lançada na íntegra com a janela de suporte mais longa do .NET.

Este guia não apresenta exemplos específicos para o .NET 9 (Versão prévia) ou o .NET 6. Se você precisa visar essas versões, poderá adaptar os exemplos do .NET 8.

Preparar para a migração

Caso ainda não tenha feito isso, identifique a lista de aplicativos que precisam ser migrados em sua assinatura atual do Azure usando o Azure PowerShell.

Antes de migrar um aplicativo para o modelo de trabalho isolado, você deve examinar detalhadamente o conteúdo deste guia. Você também deve se familiarizar com os recursos do modelo de trabalho isolado e as diferenças entre os dois modelos.

Para migrar o aplicativo, você:

  1. Siga as etapas em Migrar seu projeto local para migrar seu projeto local para o modelo de trabalho isolado.
  2. Após migrar seu projeto, faça um teste completo do aplicativo no local usando a versão 4.x do Azure Functions Core Tools.
  3. Atualize seu aplicativo de funções no Azure para o modelo isolado.

Migrar seu projeto local

A seção descreve as várias alterações que você precisa fazer no projeto local para movê-lo para o modelo de trabalho isolado. Algumas das etapas são alteradas com base na 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. Se, em vez disso, seu aplicativo estiver usando o script C# (arquivos .csx), você deverá converter para o modelo de projeto antes de continuar.

Dica

Se você estiver migrando para uma versão LTS ou STS do .NET, o Assistente de Atualização do .NET poderá 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 fazer isso, você verá erros de build no projeto. Nas etapas subsequentes, você fará as alterações correspondentes para remover esses erros.

Arquivo de projeto

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

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.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 a fim de executá-lo no modelo de trabalho isolado:

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

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

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

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

  3. Adicione o seguinte elemento OutputType ao PropertyGroup:

    <OutputType>Exe</OutputType>

  4. No ItemGroup.Lista PackageReference, substitua a referência de pacote de Microsoft.NET.Sdk.Functions pelas 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 todas as referências a outros pacotes nos namespaces Microsoft.Azure.WebJobs.*. Você substituirá esses pacotes em uma etapa posterior.

  5. Adicione o ItemGroup novo a seguir:

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

Depois que você fizer essas alterações, o projeto atualizado será semelhante ao seguinte exemplo:

<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 de extensão azureFunctions.deploySubpath por meio das configurações do usuário ou do arquivo .vscode/settings.json do seu projeto. Verifique se há dependências na versão da estrutura que possam existir fora do código do seu projeto, como parte das etapas de compilação ou de um pipeline de CI/CD.

Referências de pacote

Ao migrar para o modelo de trabalho isolado, você precisa alterar os pacotes que seu aplicativo referencia.

Atualize seu projeto, caso ainda não tenha feito isso, para referenciar as versões estáveis mais recentes de:

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

Cenário Alterações nas referências de pacote
Gatilho de temporizador Add
Microsoft.Azure.Functions.Worker.Extensions.Timer
Associações do armazenamento Substitua
Microsoft.Azure.WebJobs.Extensions.Storage
por
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues e
Microsoft.Azure.Functions.Worker.Extensions.Tables
Associações de blob Substitua referências a
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
pela versão mais recente de
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Associações de fila Substitua referências a
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
pela versão mais recente de
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Associações de tabela Substitua referências a
Microsoft.Azure.WebJobs.Extensions.Tables
pela versão mais recente de
Microsoft.Azure.Functions.Worker.Extensions.Tables
Associações do Cosmos DB Substitua referências a
Microsoft.Azure.WebJobs.Extensions.CosmosDB
e/ou
Microsoft.Azure.WebJobs.Extensions.DocumentDB
pela versão mais recente de
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Associações do barramento de serviço Substitua referências a
Microsoft.Azure.WebJobs.Extensions.ServiceBus
pela versão mais recente de
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Associações dos Hubs de Eventos Substitua referências a
Microsoft.Azure.WebJobs.Extensions.EventHubs
pela versão mais recente de
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Associações da Grade de Eventos Substitua referências a
Microsoft.Azure.WebJobs.Extensions.EventGrid
pela versão mais recente de
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
Associações do Serviço do SignalR Substitua referências a
Microsoft.Azure.WebJobs.Extensions.SignalRService
pela versão mais recente de
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Funções duráveis Substitua referências a
Microsoft.Azure.WebJobs.Extensions.DurableTask
pela versão mais recente de
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Funções duráveis
(provedor de armazenamento SQL)		 Substitua referências a
Microsoft.DurableTask.SqlServer.AzureFunctions
pela versão mais recente de
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Funções duráveis
(provedor de armazenamento Netherite)		 Substitua referências a
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
pela versão mais recente de
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
Associações do SendGrid Substitua referências a
Microsoft.Azure.WebJobs.Extensions.SendGrid
pela versão mais recente de
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Associações do Kafka Substitua referências a
Microsoft.Azure.WebJobs.Extensions.Kafka
pela versão mais recente de
Microsoft.Azure.Functions.Worker.Extensions.Kafka
Associações do RabbitMQ Substitua referências a
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
pela versão mais recente de
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.)

Confira as Associações com suporte para obter uma lista completa das extensões a serem consideradas, e confira a documentação de cada extensão para obter as instruções completas de instalação para o modelo de processo isolado. Instale a versão estável mais recente de todos os pacotes que você está direcionando.

Dica

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

Seu aplicativo de modelo de trabalho isolado não deve fazer referência a nenhum pacote nos namespaces Microsoft.Azure.WebJobs.* ou Microsoft.Azure.Functions.Extensions. Se você ainda tiver referências aos pacotes, é preciso removê-las.

Dica

Seu aplicativo também pode depender de tipos de SDK do Azure, seja como parte de seus gatilhos e associações ou como uma dependência autônoma. Você também deve aproveitar essa oportunidade para atualizá-los. 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 com o formato Azure.*.

Arquivo program.cs

Ao migrar para a execução em um processo de trabalho isolado, você precisa adicionar o arquivo Program.cs ao 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 do ASP.NET Core para melhorar o desempenho e fornecer um modelo de programação clássica quando o aplicativo usar gatilhos HTTP. Se você não pretende usar gatilhos HTTP, pode substituir a chamada a ConfigureFunctionsWebApplication por uma chamada a ConfigureFunctionsWorkerDefaults. Se você fizer isso, poderá remover a referência ao Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore do arquivo de projeto. No entanto, para obter o melhor desempenho, mesmo para funções com outros tipos de gatilho, você deve manter a FrameworkReference ASP.NET Core.

O arquivo Program.cs substituirá todos os arquivos que tenham o atributo FunctionsStartup, que normalmente é um arquivo Startup.cs. Em locais em que o código FunctionsStartup referenciaria IFunctionsHostBuilder.Services, você pode, em vez disso, adicionar instruções dentro do método .ConfigureServices() do HostBuilder em seu Program.cs. Para saber mais sobre como trabalhar com Program.cs, confira a Configuração e inicialização no guia do modelo de trabalho 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.cs, você também deve configurar qualquer filtragem de log que deve ser aplicada aos logs provenientes do código no seu projeto. No modelo de trabalho isolado, o arquivo host.json controla apenas os eventos emitidos pelo runtime do host do 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 na telemetria.

Embora você possa registrar fontes de configuração personalizadas como parte do HostBuilder, observe que elas se aplicam somente ao código no seu projeto. A configuração de gatilho e associação também é necessária para a plataforma, e ela deve ser realizada por meio dos recursos de configurações de aplicativo, referências do Key Vault ou referências da Configuração de Aplicativos.

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

Alterações de assinatura de função

Alguns tipos-chave mudam entre o modelo em processo e o modelo de trabalho isolado. Muitos deles se relacionam com os 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 de função (que também define o nome da função)
  • Como a função obtém um ILogger/ILogger<T>
  • Disparar e associar atributos e parâmetros

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

Atributos de função

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

Logging

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

No entanto, para qualquer Função que dependesse do parâmetro de método ILogger, você precisa fazer uma alteração. É recomendável que você use a injeção de dependência para obter um ILogger<T>. Use as seguintes etapas para migrar o mecanismo de registro em log da função:

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

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

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

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

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

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

Para saber mais, confira Registro em log no modelo de trabalho isolado.

Alterações de associação e gatilho

Ao alterar as referências de pacote na etapa anterior, você introduziu erros nos gatilhos e associações que serão corrigidos agora:

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

  2. Adicionar a instrução using Microsoft.Azure.Functions.Worker;.

  3. Para cada atributo de associação, altere o nome do atributo conforme especificado em sua documentação de referência, que você pode encontrar no índice Associações com suporte. Em geral, os nomes de atributo são alterados da seguinte maneira:

    • Os gatilhos normalmente permanecem nomeados da mesma maneira. Por exemplo, QueueTrigger é o nome do atributo para ambos os modelos.
    • Normalmente, as associações de entrada precisam de "Entrada" adicionada ao nome. Por exemplo, se você usou o atributo de associação de entrada CosmosDB no modelo em processo, o atributo agora seria CosmosDBInput.
    • Normalmente, as associações de saída precisam de "Saída" adicionada ao nome. Por exemplo, se você usou o atributo de associação de saída Queue 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 associação de saída de blob é representada por um atributo [Blob(...)] que inclui a propriedade Access. No modelo de trabalho isolado, o atributo de saída de blob seria [BlobOutput(...)]. A associação não requer mais a propriedade Access, assim o parâmetro pode ser removido. Então [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] se tornaria [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

  5. Mova as associações de saída para fora da lista de parâmetros de função. Se você tiver apenas uma associaçã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, confira Várias associações de saída.

  6. Consulte a documentação de referência de cada associação para se informar sobre os tipos aos quais podem ser associados. Em alguns casos, talvez seja necessário alterar o tipo. Para associações de saída, se a versão do modelo em processo tiver usado a IAsyncCollector<T>, você poderá substituí-la pela associação a uma matriz do tipo de destino: T[]. Você também pode considerar substituir a associação de saída por um objeto cliente para o serviço que ele representa, como o tipo de associação para uma associação de entrada, se disponível, ou injetando um cliente por conta própria.

  7. Se sua função incluir o parâmetro IBinder, remova-o. Substitua a funcionalidade por um objeto cliente para o serviço que ele representa, como o tipo de associaçã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 novos tipos.

Arquivo local.settings.json

O arquivo local.settings.json só é usado durante a execução local. Para obter mais informações, confira Arquivo de configurações local.

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

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

O valor configurado para `AzureWebJobsStorage`` pode ser diferente. Você não precisa alterar seu valor como parte da migração.

Arquivo host.json

Nenhuma alteração será necessária para o arquivo host.json. No entanto, se a configuração do Application Insights estiver neste arquivo do seu projeto de modelo em processo, talvez seja conveniente fazer alterações adicionais no seu arquivo Program.cs. O arquivo host.json controla apenas o log do runtime do host do Functions e, no modelo de trabalho isolado, alguns desses logs vêm diretamente do aplicativo, oferecendo mais controle. Confira Gerenciamento de 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, à medida que você trabalha com a migração. Essas alterações não são necessárias para todos os aplicativos, mas você deve avaliar se alguma é relevante para os 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 ao Application Insights do runtime do host do Functions e do código em seu projeto. O host.json permite que você configure regras para o registro do host, mas para controlar os logs provenientes do código, você precisará configurar regras de filtragem como parte do seu Program.cs. Confira Gerenciamento de 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

O gatilho HTTP para o modelo em processo pode ser semelhante ao seguinte exemplo:

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

O gatilho HTTP para a versão migrada pode ser semelhante ao seguinte exemplo:

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

Atualize seu aplicativo de funções no Azure

Atualizar seu aplicativo de funções para o modelo isolado envolve duas alterações que devem ser concluídas juntas, pois se você concluir apenas uma, o aplicativo estará em um estado de erro. Essas duas 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. Se você precisar minimizar o tempo de inatividade, considere usar um slot de preparo para testar e verificar o código migrado com a configuração atualizada no Azure. Em seguida, você pode implantar seu aplicativo totalmente migrado no slot de produção por meio de uma operação de troca.

Importante

Quando o conteúdo implantado de um aplicativo não corresponder ao runtime configurado, ele 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 atenuar o impacto disso, pois o estado de erro será resolvido em seu ambiente de preparo (não produção) antes que as alterações sejam aplicadas como apenas uma atualização para o seu ambiente de produção. Os slots também são uma defesa contra eventuais erros e permitem que você detecte outros problemas antes de chegar à produção.

Durante o processo, você ainda poderá ver erros em logs provenientes do slot de preparo (não produção). Isso é esperado, embora deva desaparecer à medida que você prossegue pelas etapas. Antes de executar a operação de troca de slots, você deve confirmar que esses erros param de ser gerados e que seu aplicativo está funcionando conforme o esperado.

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

  1. Crie um slot de implantação se ainda não tiver feito isso. Talvez você também queira se familiarizar com o processo de troca de slot e garantir que você possa fazer atualizações para o aplicativo existente com interrupção mínima.

  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 aplicativo FUNCTIONS_WORKER_RUNTIME como dotnet-isolated. FUNCTIONS_WORKER_RUNTIME não deve ser marcado como uma "configuração de slot".

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

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

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

    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ções durante a implantação. O Visual Studio apresenta isso como apenas uma operação, mas 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 o aplicativo está funcionando conforme o esperado no 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 slots ocorre como apenas uma 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 qualquer outro aplicativo que precise de migração.

Próximas etapas

Saiba mais sobre o modelo de trabalho isolado