Migrar aplicativos .NET do modelo em processo para o modelo de trabalho isolado
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:
- Migrar aplicativos do Azure Functions versão 2.x e 3.x para a versão 4.x
- Migrar aplicativos do Azure Functions versão 1.x para a versão 4.x
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ê:
- Conclua as etapas em Migrar seu projeto local para migrar seu projeto local para o modelo de trabalho isolado.
- 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.
- 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
:
Defina o valor de
PropertyGroup
:TargetFramework
paranet8.0
.Defina o valor de
PropertyGroup
:AzureFunctionsVersion
parav4
.Adicione o seguinte elemento
OutputType
aoPropertyGroup
:<OutputType>Exe</OutputType>
No
ItemGroup
.ListaPackageReference
, substitua a referência de pacote deMicrosoft.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.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 | SubstituaMicrosoft.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 aMicrosoft.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 aMicrosoft.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 aMicrosoft.Azure.WebJobs.Extensions.Tables pela versão mais recente de Microsoft.Azure.Functions.Worker.Extensions.Tables |
Associações do Cosmos DB | Substitua referências aMicrosoft.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 aMicrosoft.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 aMicrosoft.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 aMicrosoft.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 aMicrosoft.Azure.WebJobs.Extensions.SignalRService pela versão mais recente de Microsoft.Azure.Functions.Worker.Extensions.SignalRService |
Funções duráveis | Substitua referências aMicrosoft.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 aMicrosoft.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 aMicrosoft.Azure.DurableTask.Netherite.AzureFunctions pela versão mais recente de Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite |
Associações do SendGrid | Substitua referências aMicrosoft.Azure.WebJobs.Extensions.SendGrid pela versão mais recente de Microsoft.Azure.Functions.Worker.Extensions.SendGrid |
Associações do Kafka | Substitua referências aMicrosoft.Azure.WebJobs.Extensions.Kafka pela versão mais recente de Microsoft.Azure.Functions.Worker.Extensions.Kafka |
Associações do RabbitMQ | Substitua referências aMicrosoft.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 aMicrosoft.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:
Na classe da função, adicione a propriedade
private readonly ILogger<MyFunction> _logger;
, substituindoMyFunction
pelo nome da classe de função.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.Para operações de registro em log no código de função, substitua as referências ao parâmetro
ILogger
por_logger
.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:
Remova todas as instruções
using Microsoft.Azure.WebJobs;
.Adicionar a instrução
using Microsoft.Azure.Functions.Worker;
.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 seriaCosmosDBInput
. - 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 seriaQueueOutput
.
- Os gatilhos normalmente permanecem nomeados da mesma maneira. Por exemplo,
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 propriedadeAccess
. No modelo de trabalho isolado, o atributo de saída de blob seria[BlobOutput(...)]
. A associação não requer mais a propriedadeAccess
, 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")]
.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.
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.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.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:
- Altere a configuração do aplicativo de funções para usar o modelo isolado definindo a configuração
FUNCTIONS_WORKER_RUNTIME
do aplicativo comodotnet-isolated
. Certifique-se de que qualquer automação de implantação seja atualizada da mesma forma. - 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.