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 ajudarão 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 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,3
.NET 82 LTS Modelo de trabalhador isolado
.NET 7 STS (fim do suporte em 14 de maio de 2024) Modelo de trabalhador isolado
.NET 6 LTS (fim do suporte em 12 de novembro de 2024) Modelo de trabalhador isolado,
Modeloem processo 3
.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. 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 .NET 8 ainda não é suportado no modelo em processo, embora esteja disponível no modelo de trabalhador isolado. Para obter informações sobre planos do .NET 8, incluindo opções futuras para o modelo em processo, consulte a publicação Atualização do Roteiro do Azure Functions.

3 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 .NET 7 ou .NET 6. Se você precisar direcionar essas versões, poderá 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 trabalhador isolado, você deve revisar cuidadosamente o conteúdo deste guia e se familiarizar com os recursos do modelo de trabalhador isolado e as diferenças entre os dois modelos.

Para migrar o aplicativo, você irá:

  1. Conclua as etapas em Migrar seu projeto local para migrar seu projeto local para o modelo de trabalho isolado.
  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, você converterá o arquivo de projeto e atualizará 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 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 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 a net8.0.

  2. Defina o valor de PropertyGroup.AzureFunctionsVersion a 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>

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 resto desta secção irá guiá-lo através de cada um destes passos.

Atributos de função

O FunctionName atributo é substituído pelo Function atributo no modelo de trabalhador isolado. 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 adicional ILogger para sua função ou pode usar a injeção de dependência para obter um ILogger<T>arquivo . Se você já estava usando 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ê precisará 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 de no trecho de MyFunction código acima 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, isso agora seria CosmosDBInput.
    • As ligações de saída normalmente precisam de "Saída" adicionada ao seu nome. Por exemplo, se você usasse o atributo de vinculação de Queue saída 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 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ê configurou 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 gostar do 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

A atualização do seu aplicativo de função para o modelo isolado consiste em duas etapas:

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

Quando você usa o Visual Studio para publicar um projeto de modelo de trabalho isolado em um aplicativo de função existente que usa o modelo em processo, você é solicitado a permitir que o Visual Studio atualize o aplicativo de função 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 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.

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 quaisquer outros aplicativos que precisem de migração.

Próximos passos

Saiba mais sobre o modelo de trabalhador isolado