Migrar aplicativos C# do modelo em processo para o modelo de trabalho isolado

Importante

O suporte para o modelo em processo termina em 10 de novembro de 2026. Migre seus aplicativos para o modelo de trabalhador isolado seguindo as instruções deste artigo.

Este artigo explica o processo de migração segura do aplicativo de funções .NET do modelo inprocess 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. Se não, use os guias a seguir para atualizar a versão do seu host. Esses guias de migração de versão do host também ajudam você a migrar para o modelo de worker isolado à medida que os segue.

Quando há suporte, este artigo aproveita ASP.NET Core integração no modelo de trabalho isolado, o que melhora o desempenho e fornece um modelo de programação familiar quando seu aplicativo usa gatilhos HTTP.

Identificar aplicativos de funções a serem migrados

Use o script de Azure PowerShell a seguir 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á atualmente configurado para usar. Você pode mudar a assinatura primeiro executando 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 de .NET de destino

Ao migrar para o modelo de trabalhador isolado, escolha seu alvo com base em se seu aplicativo de funções e suas dependências podem rodar no .NET (anteriormente .NET Core):

  • Se seu app e suas dependências podem rodar em .NET, mire no .NET 10.
  • Se seu app depende de bibliotecas ou APIs disponíveis apenas no .NET Framework, mire no .NET Framework 4.8.

Preparar para a migração

Antes de migrar um aplicativo para o modelo de trabalhador isolado, revise cuidadosamente o conteúdo deste guia. Além disso, familiarize-se com as características do modelo de trabalhador isolado e as diferenças entre os dois modelos.

Para migrar o aplicativo:

  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, teste completamente o app localmente usando a versão 4.x do Azure Functions Core Tools.
  3. Update seu aplicativo de funções em Azure para o modelo isolado.

Migrar seu projeto local

Esta seção descreve as várias mudanças que você precisa fazer no seu projeto local para adotá-lo ao modelo de trabalhador 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.

Dica

Se você estiver migrando para o .NET 10, o Assistente de Atualização do .NET pode fazer automaticamente muitas das mudanças mencionadas nas seções a seguir.

Primeiro, converta o arquivo de projeto e atualize suas dependências. Ao trabalhar no projeto, você vê erros de build. Nas etapas subsequentes, você fará as alterações correspondentes para remover esses erros.

arquivo de projeto

O exemplo a seguir mostra um arquivo de projeto .csproj que usa .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 a fim de executá-lo no modelo de trabalho isolado:

Essas etapas pressupõem um projeto em C# local; se seu aplicativo, em vez disso, usa o script C# (arquivos .csx ), você deve converter no modelo de projeto antes de continuar.

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

  1. Defina o Sdk atributo do Project elemento para Azure.Functions.Sdk/1.0.0.

  2. Defina o valor de PropertyGroup: TargetFramework para net10.0.

  3. No ItemGroup. PackageReference lista, substitua a referência ao pacote Microsoft.NET.Sdk.Functions pelas referências a seguir. Mantenha o Microsoft.Azure.Functions.Worker pacote como referência explícita:

    <FrameworkReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.Azure.Functions.Worker" Version="2.52.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="2.1.0" />
<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.

  4. Adicione o novo ItemGroup 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="Azure.Functions.Sdk/1.0.0">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <RootNamespace>My.Namespace</RootNamespace>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="2.52.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="2.1.0" />
    <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 azureFunctions.deploySubpath extensão por meio das configurações do usuário ou do arquivo .vscode/settings.json do 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 build ou de um pipeline de CI/CD.

Referências de pacote

Ao migrar para o modelo de trabalhador isolado, mude os pacotes que sua aplicação referencia.

Se ainda não fez isso, atualize seu projeto para usar 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 Adicionar
Microsoft.Azure. Functions.Worker.Extensions.Timer
Vinculações de 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
com a 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
com a versão mais recente de
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Vinculações de tabela Substitua referências a
Microsoft.Azure.WebJobs.Extensions.Tables
com a 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
com a 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
com a versão mais recente de
Microsoft.Azure. Functions.Worker.Extensions.ServiceBus
Vinculações do Hubs de Eventos Substitua referências a
Microsoft.Azure.WebJobs.Extensions.EventHubs
com a 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
com a versão mais recente de
Microsoft.Azure. Functions.Worker.Extensions.EventGrid
vinculações do Serviço do SignalR Substitua referências a
Microsoft.Azure.WebJobs.Extensions.SignalRService
com a versão mais recente de
Microsoft.Azure. Functions.Worker.Extensions.SignalRService
Durable Functions Substitua referências a
Microsoft.Azure.WebJobs.Extensions.DurableTask
com a versão mais recente de
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Durable Functions
(provedor de armazenamento SQL)		 Substitua referências a
Microsoft.DurableTask.SqlServer.AzureFunctions
com a versão mais recente de
Microsoft.Azure. Functions.Worker.Extensions.DurableTask.SqlServer
Durable Functions
(provedor de armazenamento Netherite)		 Substitua referências a
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
com a versão mais recente de
Microsoft.Azure. Functions.Worker.Extensions.DurableTask.Netherite
Ligações do SendGrid Substitua referências a
Microsoft.Azure.WebJobs.Extensions.SendGrid
com a versão mais recente de
Microsoft.Azure. Functions.Worker.Extensions.SendGrid
Associações do Kafka Substitua referências a
Microsoft.Azure.WebJobs.Extensions.Kafka
com a versão mais recente de
Microsoft.Azure. Functions.Worker.Extensions.Kafka
Vinculações do RabbitMQ Substitua referências a
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
com a 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. Certifique-se de instalar a versão estável mais recente de qualquer pacote que você almeja.

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 Barramento de Serviço tem alterações significativas na estrutura entre as versões 4.x e 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 a essas, elas devem ser removidas.

Dica

Seu aplicativo também pode depender de tipos de SDK do Azure, 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 executar em um processo de trabalho isolado, adicione um arquivo Program.cs 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 ASP.NET Core integração 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, pode substituir a chamada para ConfigureFunctionsWebApplication por uma chamada para ConfigureFunctionsWorkerDefaults. Se você fizer isso, poderá remover a referência a 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 o FrameworkReference para ASP.NET Core.

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

Os exemplos padrão Program.cs descritos anteriormente configuram o Application Insights usando o Application Insights SDK. Para a configuração Application Insights baseada em OpenTelemetry descrita no guia do modelo de trabalhador isolado, veja Application Insights. Em seu Program.cs, você 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 host.json controla apenas os eventos emitidos pelo runtime do host do Functions. Se você não configurar regras de filtragem em 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 da HostBuilder, elas se aplicam somente ao código em 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 arquivo existente FunctionsStartup para o Program.cs , você pode excluir o FunctionsStartup atributo 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. Muitas dessas mudanças estão relacionadas aos atributos, parâmetros e tipos de retorno que compõem a assinatura da função. Para cada uma das suas funções, faça 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 executar uma substituição da cadeia de caracteres em seu projeto.

Registro em log

No modelo em processo, você pode incluir um parâmetro opcional ILogger para sua função ou usar a injeção de dependência para obter um ILogger<T>. Se o seu aplicativo já usava 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. 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 gatilho e vinculação

Quando você alterou as referências do pacote em uma etapa anterior, introduziu erros para seus gatilhos e associações que agora você pode corrigir:

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

  2. Adicione uma 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, é necessário adicionar Input ao nome das associações de entrada. Por exemplo, se você usou o atributo de associação de entrada CosmosDB no modelo em processo, o atributo agora seria CosmosDBInput.
    • Normalmente, é necessário adicionar Output ao nome das associações de saída. 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 vinculação não requer mais essa Access propriedade, então você pode remover esse parâmetro. Então [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] se torna [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 ligação de saída, pode aplicar essa ligação 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 ligações de saída, se a versão do modelo em processo usou um IAsyncCollector<T>, você pode substituir esse tipo vinculando a um array do tipo alvo: 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.

Migrar para fluxo de entrada/saída HTTP assíncrono

Se uma função acionada por HTTP usar integração com ASP.NET Core, substitua leituras e gravações síncronas de fluxos de solicitação e resposta HTTP por métodos assíncronos. Operações síncronas podem falhar com InvalidOperationException: Synchronous operations are disallowed. Por exemplo, substitua ReadToEnd por ReadToEndAsync, Write com WriteAsyncWriteStringAsync, WriteString e Flush por FlushAsync.

Quando você aguarda essas operações, marque o método de função como async e envolva seu tipo de retorno em Task<T>. Por exemplo, mude IActionResult para Task<IActionResult> ou MultiResponse para Task<MultiResponse>. O ASP.NET Core não permite, por padrão, E/S síncrona de solicitação e resposta porque a E/S síncrona pode causar esgotamento do pool de threads. Se uma dependência ou serializador não suporta E/S assíncrona, veja serialização JSON com integração ASP.NET Core para instruções que permitem I/O síncrona (AllowSynchronousIO) como opção de compatibilidade.

arquivo local.settings.json

O arquivo local.settings.json só é usado ao ser executado localmente. Para obter mais informações, confira Arquivo de configurações local.

Ao migrar da execução no próprio processo para a execução em um processo de trabalho isolado, é necessário alterar o valor FUNCTIONS_WORKER_RUNTIME para dotnet-isolated. Certifique-se de que seu arquivolocal.settings.json contenha pelo menos os seguintes elementos:

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

O valor para AzureWebJobsStorage o qual você tem pode ser diferente. Não é necessário alterar esse valor durante a migração.

Arquivo host.json

Nenhuma alteração é necessária no arquivo host.json. No entanto, se a configuração do Application Insights estiver nesse arquivo do seu projeto de modelo em processo, talvez você queira fazer mais alterações no arquivo Program.cs . O arquivo host.json controla apenas o registro em log do runtime do host do Functions. No modelo de trabalhador isolado, alguns desses logs vêm diretamente da sua aplicação, dando 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 seus cenários.

Serialização JSON

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

Como o modelo em processo usava Newtonsoft.Json, também verifique os atributos de serialização em quaisquer tipos aos quais suas funções se vinculam. System.Text.Json ignora atributos como [JsonProperty] e [JsonIgnore] de Newtonsoft.Json. Ele vincula a propriedade afetada ao seu valor padrão sem reportar erro. Ou substitui-los por seus equivalentes System.Text.Json , como [JsonPropertyName], ou configure Newtonsoft.Json para a camada que gerencia a carga útil.

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 log do host, mas para controlar os logs provenientes do seu código, você precisa configurar regras de filtragem como parte do 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ção de gatilho HTTP

O exemplo a seguir compara uma função acionada por HTTP antes e depois da migração com o modelo de trabalhador isolado.

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(ILogger<HttpTriggerCSharp> 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ções no Azure

Depois de migrar seu projeto local, atualize a configuração do seu app de funções e implante o código migrado para completar a transição para o modelo de trabalhador isolado.

Antes de publicar seu projeto migrado

Antes de publicar seu projeto de código atualizado, planeje completar estas duas mudanças juntas:

  • Mude a configuração do FUNCTIONS_WORKER_RUNTIME aplicativo para dotnet-isolated.
  • Publique o projeto migrado de trabalhador isolado no seu aplicativo de trabalho.

Cada alteração reinicia o app. Depois que você conclui a primeira alteração, o código implantado e o runtime configurado não coincidem, o que causa um erro de incompatibilidade entre runtime e payload (AZFD0013) até que você complete a segunda alteração.

Quando possível, use um slot de preparo durante a migração. Um slot de staging oferece estes benefícios:

  • Evita que o estado de erro temporário resultante do desajuste entre código e runtime saia da produção.
  • Permite testar o código migrado e a configuração antes de trocá-los para produção.

Você poderá ver erros nos logs do slot de staging ao concluir as duas alterações. Antes de trocar o slot, confirme se os erros pararam e que o app funciona como esperado.

Atualize seu aplicativo de funções usando slots

Siga estas etapas para atualizar seu aplicativo de função para o modelo de trabalhador isolado usando um slot de preparo:

  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 no aplicativo existente com mínima interrupção.

  2. Altere a configuração do slot de teste (fora de produção) para usar o modelo de worker isolado, definindo a configuração da aplicação FUNCTIONS_WORKER_RUNTIME como dotnet-isolated. Não marque FUNCTIONS_WORKER_RUNTIME como uma configuração de slot.

    Se você também estiver visando uma versão diferente do .NET como parte da sua atualização, altere a configuração de pilha. Para isso, consulte Atualizar a configuração da pilha. Você pode usar as mesmas instruções para quaisquer atualizações futuras de versão .NET que você fizer.

    Se você tiver algum provisionamento automatizado de infraestrutura, 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 ter como destino a versão correta do .NET.

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

    Se você usar 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, Visual Studio solicitará que você atualize o aplicativo de funções durante a implantação. O Visual Studio apresenta essa atualização como uma única operação, mas essas atualizações ainda são duas operações separadas. Você ainda poderá ver erros nos seus logs do slot de teste (fora de produção) durante o estado provisório.

  4. Confirme se o aplicativo está funcionando conforme o esperado no ambiente de teste (fora de produção).

  5. Execute uma operação de troca de slot para aplicar as alterações feitas no slot de teste (não produtivo) ao slot de produção. Uma troca de slots ocorre como uma única atualização, evitando a introdução de um estado de erro provisório em seu ambiente de produção.

  6. Confirme se o aplicativo está funcionando conforme o esperado no ambiente 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óxima etapa

Saiba mais sobre como executar funções do Azure C# no modelo de trabalhador isolado

  • Última atualização em