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 ajudarão 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 do Functions 1,3
.NET 82 LTS Modelo de trabalho isolado
.NET 7 STS (fim do suporte 14 de maio de 2024) Modelo de trabalho isolado
.NET 6 LTS (fim do suporte 12 de novembro de 2024) Modelo de trabalho isolado,
Modelo em processo3
.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 só dá suporte a versões LTS do .NET. 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 .NET 8 ainda não tem suporte no modelo em processo, embora esteja disponível no modelo de trabalho isolado. Para obter informações sobre planos do .NET 8, incluindo futuras opções para o modelo em processo, confira a postagem Atualização do roteiro do Azure Functions.

3 O suporte termina para o modelo em processo 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.

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 7 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 completamente o conteúdo deste guia e familiarizar-se com os recursos do modelo de trabalho isolado e as diferenças entre os dois modelos.

Para migrar o aplicativo, você:

  1. Conclua 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, você converterá o arquivo de projeto e atualizará 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>

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ê em cada uma dessas etapas.

Atributos de função

O atributo FunctionName é substituído pelo atributo Function no modelo de trabalho isolado. 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.

Registrando em log

No modelo em processo, você pode incluir um parâmetro de ILogger adicional 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ê precisará 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 acima 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, isso 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, isso 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 consiste em duas etapas:

  1. Altere a configuração do aplicativo de funções para usar o modelo isolado definindo a configuração FUNCTIONS_WORKER_RUNTIME do aplicativo como dotnet-isolated. Certifique-se de que qualquer automação de implantação seja atualizada da mesma forma.
  2. Publique seu projeto migrado para o aplicativo de funções atualizado.

Ao usar o Visual Studio para publicar um projeto de modelo de trabalho isolado em um aplicativo de funções existente que usa o modelo em processo, você será solicitado a permitir que o Visual Studio atualize o aplicativo de funções durante a implantação. Isso realiza as duas etapas ao mesmo tempo.

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.

Depois de concluir essas etapas, seu aplicativo foi totalmente migrado para o 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