Migrar aplicações da versão 3.x das Funções do Azure para a versão 4.x

Artigo
02/11/2023
22 minutos para ler

Funções do Azure versão 4.x é altamente compatível com a versão 3.x. A maioria das aplicações deve atualizar com segurança para 4.x sem precisar de alterações significativas de código. Para obter mais informações sobre as versões de runtime das Funções, veja descrição geral Funções do Azure versões de runtime.

Importante

A partir de 13 de dezembro de 2022, as aplicações de funções em execução nas versões 2.x e 3.x do Funções do Azure runtime atingiram o fim de vida (EOL) do suporte alargado.

Após o prazo, as aplicações de funções podem ser criadas e implementadas a partir do pipeline ci/CD DevOps e todas as aplicações existentes continuam a ser executadas sem alterações interruptivas. No entanto, as suas aplicações não são elegíveis para novas funcionalidades, patches de segurança e otimizações de desempenho. Receberá suporte de serviço relacionado assim que os atualizar para a versão 4.x.

O fim do suporte para estas versões de runtime deve-se ao fim do suporte para o .NET Core 3.1, que é exigido por estas versões de runtime mais antigas. Este requisito afeta todos os idiomas de runtime Funções do Azure (por exemplo, .NET, Python, node.js, PowerShell, etc.).

Recomendamos vivamente que migre as suas aplicações de funções para a versão 4.x do runtime das Funções ao seguir este artigo.

A versão 1.x das funções ainda é suportada para aplicações de funções C# que requerem a .NET Framework. O suporte de pré-visualização está agora disponível nas Funções 4.x para executar funções C# no .NET Framework 4.8.

Este artigo explica-lhe o processo de migração segura da aplicação de funções para ser executado na versão 4.x do runtime das Funções. Uma vez que as instruções de atualização do projeto dependem da linguagem, certifique-se de que escolhe a sua linguagem de desenvolvimento no seletor na parte superior do artigo.

Escolha o seu .NET de destino

Na versão 3.x do runtime de Funções, a aplicação de funções C# destina-se a .NET Core 3.1. Quando migra a aplicação de funções para a versão 4.x, tem a oportunidade de escolher a versão de destino do .NET. Pode atualizar o projeto C# para uma das seguintes versões do .NET, todas as quais podem ser executadas na versão 4.x das Funções:

Versão do .NET	Modelo dos processos^*
.NET 7	Processo de trabalho isolado
.NET 6	Processo de trabalho isolado
.NET 6	Em processo

^*A execução no processo só é suportada para versões de Suporte de Longo Prazo (LTS) do .NET. As versões de Suporte de Termos Padrão (STS) e .NET Framework são suportadas pelo processo de trabalho isolado das funções .NET do Azure.

Dica

Na versão 3.x do runtime das Funções, se estiver no .NET 5, recomendamos que atualize para .NET 7. Se estiver no .NET Core 3.1, recomendamos que atualize para o .NET 6 (em processo) para um caminho de atualização rápido.

Se estiver à procura de mudar para uma versão .NET de Suporte de Longo Prazo (LTS), recomendamos que atualize para o .NET 6.

Migrar para o modelo de trabalho isolado do .NET para obter todos os benefícios fornecidos pelo Funções do Azure processo de trabalho isolado do .NET. Para obter mais informações sobre as vantagens do processo de trabalho isolado do .NET, veja Melhoramento do processo de trabalho isolado do .NET. Para obter mais informações sobre o suporte da versão .NET, veja Versões suportadas.

A atualização do .NET Core 3.1 para o .NET 6 em execução no processo requer atualizações mínimas para o seu projeto e praticamente nenhuma atualização ao código. Mudar para o modelo de processo de trabalho isolado requer que faça alterações ao código, mas proporciona a flexibilidade de poder executar facilmente em qualquer versão futura do .NET. Para obter uma comparação de funcionalidades e funcionalidades entre os dois modelos de processo, veja Diferenças entre o processo em processo e o processo de trabalho isolado .NET Funções do Azure.

Prepare para a migração

Antes de atualizar a aplicação para a versão 4.x do runtime das Funções, deve realizar as seguintes tarefas:

Reveja a lista de alterações interruptivas entre 3.x e 4.x.
Execute o validador de pré-atualização.
Identifique a lista de Aplicações de Funções v2&v3 na sua Subscrição do Azure atual com o Azure PowerShell.
Sempre que possível, atualize o ambiente do projeto local para a versão 4.x. Teste totalmente a sua aplicação localmente com a versão 4.x do Funções do Azure Core Tools.
Atualize a aplicação de funções no Azure para a nova versão. Se precisar de minimizar o tempo de inatividade, considere utilizar um bloco de teste para testar e verificar a aplicação migrada no Azure na nova versão do runtime. Em seguida, pode implementar a sua aplicação com as definições de versão atualizadas no bloco de produção. Para obter mais informações, veja Migrar com blocos.
Publicou novamente o projeto migrado para a aplicação de funções atualizada. Quando utiliza o Visual Studio para publicar um projeto de versão 4.x numa aplicação de funções existente numa versão inferior, é-lhe pedido que permita que o Visual Studio atualize a aplicação de funções para a versão 4.x durante a implementação. Esta atualização utiliza o mesmo processo definido em Migrar sem blocos.

Executar o validador de pré-atualização

As Funções do Azure disponibilizam um validador de pré-atualização, que ajuda a identificar potenciais problemas ao migrar a sua aplicação de funções para a versão 4.x. Para executar o validador de pré-atualização:

No portal do Azure, navegue para a sua aplicação de funções.
Abra a página Diagnosticar e resolver problemas .
No Diagnóstico da Aplicação de Funções, comece a Functions 4.x Pre-Upgrade Validator escrever e, em seguida, selecione-o na lista.
Após a validação ser concluída, reveja as recomendações e resolva quaisquer problemas na sua aplicação. Se precisar de fazer alterações à sua aplicação, confirme que valida as alterações em relação à versão 4.x do runtime das Funções, quer localmente, utilizando Funções do Azure Core Tools v4 ou utilizando um bloco de teste.

Identificar aplicações de funções a atualizar

Utilize o seguinte script do PowerShell para gerar uma lista de aplicações de funções na sua subscrição que atualmente visam as versões 2.x ou 3.x:

$Subscription = '<YOUR SUBSCRIPTION ID>' 
 
Set-AzContext -Subscription $Subscription | Out-Null

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     if ($App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"] -like '*3*')
     {
          $AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
     }
}

$AppInfo

Atualizar o projeto local

As instruções de atualização dependem do idioma. Se não vir o seu idioma, selecione-o no seletor na parte superior do artigo.

Selecione o separador que corresponde à versão de destino do .NET e ao modelo de processo pretendido (processo de trabalho em processo ou isolado).

Ficheiro .csproj

O exemplo seguinte é um ficheiro de projeto .csproj que utiliza o .NET Core 3.1 na versão 3.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.13" />
  </ItemGroup>
  <ItemGroup>
    <Reference Include="Microsoft.CSharp" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Utilize um dos seguintes procedimentos para atualizar este ficheiro XML para ser executado na versão 4.x das Funções:

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

Alterar o valor de PropertyGroup.TargetFramework para net6.0.
Alterar o valor de PropertyGroup.AzureFunctionsVersion para v4.

Substitua o existente ItemGroup.PackageReference list com o seguinte ItemGroup:

<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
</ItemGroup>

Depois de efetuar estas alterações, o projeto atualizado deverá ter o seguinte exemplo:


<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>

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

Alterar o valor de PropertyGroup.TargetFramework para net6.0.
Alterar o valor de PropertyGroup.AzureFunctionsVersion para v4.
Adicione o seguinte OutputType elemento ao PropertyGroup:
```
<OutputType>Exe</OutputType>
```

Substitua o existente ItemGroup.PackageReference list com o seguinte ItemGroup:

<ItemGroup>
  <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.8.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.7.0" />
</ItemGroup>

Adicione o seguinte novo ItemGroup:

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

Depois de efetuar estas alterações, o projeto atualizado deverá ter o seguinte exemplo:


<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.6.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.3.0" />
  </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>

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

Alterar o valor de PropertyGroup.TargetFramework para net7.0.
Alterar o valor de PropertyGroup.AzureFunctionsVersion para v4.
Adicione o seguinte OutputType elemento ao PropertyGroup:
```
<OutputType>Exe</OutputType>
```

Substitua o existente ItemGroup.PackageReference list com o seguinte ItemGroup:

<ItemGroup>
  <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.8.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.7.0" />
</ItemGroup>

Adicione o seguinte novo ItemGroup:

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

Depois de efetuar estas alterações, o projeto atualizado deverá ter o seguinte exemplo:


<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net7.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.8.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.7.0" />
  </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>

ficheiro program.cs

Ao migrar para ser executado num processo de trabalho isolado, tem de adicionar o seguinte ficheiro program.cs ao seu projeto:

Não é necessário um ficheiro program.cs durante a execução em processo.

using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .Build();

host.Run();

using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .Build();

host.Run();

ficheiro local.settings.json

O ficheiro local.settings.json só é utilizado quando é executado localmente. Para obter informações, veja Ficheiro de definições locais. Ao migrar da execução em processo para a execução num processo de trabalho isolado, tem de alterar o FUNCTIONS_WORKER_RUNTIME valor, tal como no exemplo seguinte:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet"
    }
}

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

Alterações ao espaço de nomes

As funções C# executadas num processo de trabalho isolado utilizam bibliotecas num espaço de nomes diferente das bibliotecas utilizadas durante a execução em processo. Geralmente, as bibliotecas no processo estão no espaço de nomes Microsoft.Azure.WebJobs.*. As aplicações de funções do processo de trabalho isolado utilizam bibliotecas no espaço de nomes Microsoft.Azure.Functions.Worker.*. Pode ver o efeito destas alterações ao espaço de nomes nas using instruções nos exemplos de modelo de acionador HTTP que se seguem.

Alterações ao nome da classe

Algumas classes-chave alteram os nomes como resultado de diferenças entre AS APIs do processo de trabalho no processo no processo e isoladas.

A tabela seguinte indica as principais classes .NET utilizadas pelas Funções que podem ser alteradas ao migrar a partir do processo:

.NET Core 3.1	.NET 6 (em processo)	.NET 6 (isolado)	.NET 7
`FunctionName` (atributo)	`FunctionName` (atributo)	`Function` (atributo)	`Function` (atributo)
`HttpRequest`	`HttpRequest`	`HttpRequestData`	`HttpRequestData`
`OkObjectResult`	`OkObjectResult`	`HttpResponseData`	`HttpResponseData`

Também podem existir diferenças de nome de classe nos enlaces. Para obter mais informações, veja os artigos de referência para os enlaces específicos.

Modelo de acionador HTTP

As diferenças entre o processo de trabalho no processo no processo e o processo de trabalho isolado podem ser vistas nas funções acionadas por HTTP. O modelo de acionador HTTP para a versão 3.x (em processo) tem o seguinte exemplo:

using System;
using System.IO;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;

namespace Company.Function
{
    public static class HttpTriggerCSharp
    {
        [FunctionName("HttpTriggerCSharp")]
        public static async Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.AuthLevelValue, "get", "post", Route = null)] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            string name = req.Query["name"];

            string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
            dynamic data = JsonConvert.DeserializeObject(requestBody);
            name = name ?? data?.name;

            string responseMessage = string.IsNullOrEmpty(name)
                ? "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response."
                : $"Hello, {name}. This HTTP triggered function executed successfully.";

            return new OkObjectResult(responseMessage);
        }
    }
}

O modelo de acionador HTTP para a versão migrada tem o seguinte exemplo:

O mesmo que a versão 3.x (em processo).

using System.Net;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public class HttpTriggerCSharp
    {
        private readonly ILogger _logger;

        public HttpTriggerCSharp(ILoggerFactory loggerFactory)
        {
            _logger = loggerFactory.CreateLogger<HttpTriggerCSharp>();
        }

        [Function("HttpTriggerCSharp")]
        public HttpResponseData Run([HttpTrigger(AuthorizationLevel.AuthLevelValue, "get", "post")] HttpRequestData req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            var response = req.CreateResponse(HttpStatusCode.OK);
            response.Headers.Add("Content-Type", "text/plain; charset=utf-8");

            response.WriteString("Welcome to Azure Functions!");

            return response;
        }
    }
}

using System.Net;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public class HttpTriggerCSharp
    {
        private readonly ILogger _logger;

        public HttpTriggerCSharp(ILoggerFactory loggerFactory)
        {
            _logger = loggerFactory.CreateLogger<HttpTriggerCSharp>();
        }

        [Function("HttpTriggerCSharp")]
        public HttpResponseData Run([HttpTrigger(AuthorizationLevel.AuthLevelValue, "get", "post")] HttpRequestData req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            var response = req.CreateResponse(HttpStatusCode.OK);
            response.Headers.Add("Content-Type", "text/plain; charset=utf-8");

            response.WriteString("Welcome to Azure Functions!");

            return response;
        }
    }
}

Para atualizar o projeto para Funções do Azure 4.x:

Atualize a instalação local do Funções do Azure Core Tools para a versão 4.x.
Atualize o pacote de extensões Funções do Azure da sua aplicação para 2.x ou superior. Para obter mais informações, veja Alterações interruptivas.

Se necessário, mude para uma das versões Java suportadas na versão 4.x.

Atualize o ficheiro da POM.xml aplicação para modificar a FUNCTIONS_EXTENSION_VERSION definição para ~4, como no exemplo seguinte:

<configuration>
    <resourceGroup>${functionResourceGroup}</resourceGroup>
    <appName>${functionAppName}</appName>
    <region>${functionAppRegion}</region>
    <appSettings>
        <property>
            <name>WEBSITE_RUN_FROM_PACKAGE</name>
            <value>1</value>
        </property>
        <property>
            <name>FUNCTIONS_EXTENSION_VERSION</name>
            <value>~4</value>
        </property>
    </appSettings>
</configuration>

Se necessário, mude para uma das versõesNode.js suportadas na versão 4.x.

Aproveite esta oportunidade para atualizar para o PowerShell 7.2, o que é recomendado. Para obter mais informações, veja Versões do PowerShell.

Se estiver a utilizar o Python 3.6, mude para uma das versões suportadas.

Atualizar a aplicação de funções no Azure

Tem de atualizar o runtime do anfitrião da aplicação de funções no Azure para a versão 4.x antes de publicar o projeto migrado. A versão de runtime utilizada pelo anfitrião de Funções é controlada pela definição da aplicação FUNCTIONS_EXTENSION_VERSION , mas em alguns casos outras definições também têm de ser atualizadas. Tanto as alterações de código como as alterações às definições da aplicação exigem que a aplicação de funções seja reiniciada.

A forma mais fácil é atualizar sem blocos e, em seguida, voltar a publicar o projeto da aplicação. Também pode minimizar o tempo de inatividade na sua aplicação e simplificar a reversão ao atualizar com blocos.

Atualizar sem blocos

A forma mais simples de atualizar para v4.x é definir a definição da aplicação FUNCTIONS_EXTENSION_VERSION como ~4 na sua aplicação de funções no Azure. Tem de seguir um procedimento diferente num site com blocos.

CLI do Azure
Azure PowerShell

az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

Update-AzFunctionAppSetting -AppSetting @{"FUNCTIONS_EXTENSION_VERSION" = "~4"} -Name <APP_NAME> -ResourceGroupName <RESOURCE_GROUP_NAME> -Force

Durante a atualização, também tem de definir outra definição, que difere entre o Windows e o Linux.

Ao executar no Windows, também tem de ativar o .NET 6.0, que é exigido pela versão 4.x do runtime.

az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

O .NET 6 é necessário para aplicações de funções em qualquer idioma em execução no Windows.

Ao executar no Windows, também tem de ativar o .NET 6.0, que é exigido pela versão 4.x do runtime.

Set-AzWebApp -NetFrameworkVersion v6.0 -Name <APP_NAME> -ResourceGroupName <RESOURCE_GROUP_NAME>

O .NET 6 é necessário para aplicações de funções em qualquer idioma em execução no Windows.

Também poderá ter de atualizar a definição do linuxFxVersion site para direcionar a sua versão de idioma específica. Se já tiver o valor correto do linuxFxVersion conjunto, pode ignorar este passo. Para obter mais informações, veja Valores válidoslinuxFxVersion.

As aplicações do PowerShell não são suportadas no Linux antes das Funções 4.x. Este facto significa que não deve precisar de atualizar uma aplicação de funções do PowerShell em execução no Linux.

az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "DOTNET|6.0"

Se estiver a migrar para o processo de trabalho isolado das Funções .NET, utilize DOTNET-ISOLATED|6.0 ou DOTNET-ISOLATED|7.0 para --linux-fx-version.

az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Java|11"

O --linux-fx-version valor tem de corresponder à versão java de destino.

az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Node|16"

O --linux-fx-version valor tem de corresponder à versão de destino Node.js.

az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Python|3.9"

O --linux-fx-version valor tem de corresponder à versão de destino do PowerShell.

Neste exemplo, substitua <APP_NAME> pelo nome da aplicação de funções e <RESOURCE_GROUP_NAME> pelo nome do grupo de recursos.

Agora, pode voltar a publicar o projeto de aplicação que foi migrado para ser executado na versão 4.x.

Atualizar com blocos

A utilização de blocos de implementação é uma boa forma de atualizar a aplicação de funções para o runtime v4.x a partir de uma versão anterior. Ao utilizar um bloco de teste, pode executar a sua aplicação na nova versão de runtime no bloco de teste e mudar para produção após a verificação. Os blocos também fornecem uma forma de minimizar o tempo de inatividade durante a atualização. Se precisar de minimizar o período de indisponibilidade, siga os passos em Atualização mínima de tempo de inatividade.

Depois de verificar a sua aplicação no bloco atualizado, pode trocar a aplicação e as novas definições de versão para produção. Esta troca requer a definição WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 no bloco de produção. A forma como adiciona esta definição afeta a quantidade de tempo de inatividade necessário para a atualização.

Atualização padrão

Se a aplicação de funções com capacidade para blocos conseguir lidar com o tempo de inatividade de um reinício completo, pode atualizar a WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS definição diretamente no bloco de produção. Uma vez que a alteração desta definição diretamente no bloco de produção causa um reinício que afeta a disponibilidade, considere fazer esta alteração num momento de tráfego reduzido. Em seguida, pode trocar na versão atualizada a partir do bloco de teste.

Atualmente, o Update-AzFunctionAppSetting cmdlet do PowerShell não suporta blocos. Tem de utilizar a CLI do Azure ou a portal do Azure.

Utilize o seguinte comando para definir WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 no bloco de produção:
```
az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0  -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> 
```
Neste exemplo, substitua <APP_NAME> pelo nome da aplicação de funções e <RESOURCE_GROUP_NAME> pelo nome do grupo de recursos. Este comando faz com que a aplicação em execução no bloco de produção seja reiniciada.

Utilize o seguinte comando para também definir WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS no bloco de teste:

az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

Utilize o seguinte comando para alterar FUNCTIONS_EXTENSION_VERSION e atualizar o bloco de teste para a nova versão do runtime:

az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

A versão 4.x do runtime de Funções requer .NET 6 no Windows. No Linux, as aplicações .NET também têm de atualizar para .NET 6. Utilize o seguinte comando para que o runtime possa ser executado no .NET 6:
- Windows
- Linux
Ao executar no Windows, também tem de ativar o .NET 6.0, que é exigido pela versão 4.x do runtime.
```
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
```
O .NET 6 é necessário para aplicações de funções em qualquer idioma em execução no Windows.
Também poderá ter de atualizar a definição do linuxFxVersion site para direcionar a sua versão de idioma específica. Se já tiver o valor correto do linuxFxVersion conjunto, pode ignorar este passo. Para obter mais informações, veja Valores válidoslinuxFxVersion.

As aplicações do PowerShell não são suportadas no Linux antes das Funções 4.x. Este facto significa que não deve precisar de atualizar uma aplicação de funções do PowerShell em execução no Linux.
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "DOTNET|6.0"
```
Se estiver a migrar para o processo de trabalho isolado das Funções .NET, utilize DOTNET-ISOLATED|6.0 ou DOTNET-ISOLATED|7.0 para --linux-fx-version.
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Java|11"
```
O --linux-fx-version valor tem de corresponder à versão java de destino.
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Node|16"
```
O --linux-fx-version valor tem de corresponder à versão de destino Node.js.
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Python|3.9"
```
O --linux-fx-version valor tem de corresponder à versão de destino do PowerShell.
Neste exemplo, substitua <APP_NAME> pelo nome da aplicação de funções e <RESOURCE_GROUP_NAME> pelo nome do grupo de recursos.
Se o projeto de código necessitar de atualizações para ser executado na versão 4.x, implemente essas atualizações no bloco de teste agora.
Confirme que a aplicação de funções é executada corretamente no ambiente de teste atualizado antes de trocar.

Utilize o seguinte comando para trocar o bloco de teste atualizado para produção:

az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production

Atualização mínima do tempo de inatividade

Para minimizar o tempo de inatividade na sua aplicação de produção, pode trocar a WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS definição do bloco de teste para produção. Depois disso, pode trocar na versão atualizada a partir de um bloco de teste pré-configurado.

Utilize o seguinte comando para definir WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 no bloco de teste:

az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

Utilize os seguintes comandos para trocar o bloco pela nova definição para produção e, ao mesmo tempo, restaurar a definição de versão no bloco de teste.
```
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~3 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
```
Poderá ver erros do bloco de teste durante o tempo entre a troca e a versão de runtime que está a ser restaurada no teste. Este erro pode ocorrer porque ter WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 apenas em teste durante uma troca remove a FUNCTIONS_EXTENSION_VERSION definição em teste. Sem a definição de versão, o bloco está num mau estado. Atualizar a versão no bloco de teste logo após a troca deve colocar o bloco novamente num bom estado e, se necessário, chamará a reversão das alterações. No entanto, qualquer reversão da troca também requer que remova WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 diretamente da produção antes da troca para evitar os mesmos erros na produção observados em teste. Esta alteração na definição de produção provocaria um reinício.
Utilize o seguinte comando para voltar a definir WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 no bloco de teste:
```
az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
```
Neste momento, ambos os blocos foram WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 definidos.

Utilize o seguinte comando para alterar FUNCTIONS_EXTENSION_VERSION e atualizar o bloco de teste para a nova versão do runtime:

az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

A versão 4.x do runtime de Funções requer .NET 6 no Windows. No Linux, as aplicações .NET também têm de atualizar para .NET 6. Utilize o seguinte comando para que o runtime possa ser executado no .NET 6:
- Windows
- Linux
Ao executar no Windows, também tem de ativar o .NET 6.0, que é exigido pela versão 4.x do runtime.
```
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
```
O .NET 6 é necessário para aplicações de funções em qualquer idioma em execução no Windows.
Também poderá ter de atualizar a definição do linuxFxVersion site para direcionar a sua versão de idioma específica. Se já tiver o valor correto do linuxFxVersion conjunto, pode ignorar este passo. Para obter mais informações, veja Valores válidoslinuxFxVersion.

As aplicações do PowerShell não são suportadas no Linux antes das Funções 4.x. Este facto significa que não deve precisar de atualizar uma aplicação de funções do PowerShell em execução no Linux.
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "DOTNET|6.0"
```
Se estiver a migrar para o processo de trabalho isolado das Funções .NET, utilize DOTNET-ISOLATED|6.0 ou DOTNET-ISOLATED|7.0 para --linux-fx-version.
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Java|11"
```
O --linux-fx-version valor tem de corresponder à versão java de destino.
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Node|16"
```
O --linux-fx-version valor tem de corresponder à versão de destino Node.js.
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Python|3.9"
```
O --linux-fx-version valor tem de corresponder à versão de destino do PowerShell.
Neste exemplo, substitua <APP_NAME> pelo nome da aplicação de funções e <RESOURCE_GROUP_NAME> pelo nome do grupo de recursos.
Se o projeto de código necessitar de atualizações para ser executado na versão 4.x, implemente essas atualizações no bloco de teste agora.
Confirme que a aplicação de funções é executada corretamente no ambiente de teste atualizado antes de trocar.

Utilize o seguinte comando para trocar o bloco de teste atualizado e pré-configurado para produção:

az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production

Alterações interruptivas entre 3.x e 4.x

Seguem-se as principais alterações interruptivas a ter em conta antes de atualizar uma aplicação 3.x para 4.x, incluindo alterações interruptivas específicas do idioma. Para obter uma lista completa, veja Funções do Azure problemas do GitHub com o nome Alteração Interrupção: Aprovado.

Se não vir a sua linguagem de programação, selecione-a na parte superior da página.

Runtime

Funções do Azure proxies é uma funcionalidade legada para as versões 1.x a 3.x do Funções do Azure runtime. O suporte para proxies de Funções pode ser reativado na versão 4.x para que possa atualizar com êxito as suas aplicações de funções para a versão de runtime mais recente. Assim que possível, deve mudar para integrar as suas aplicações de funções com o Azure Gestão de API. O API Management permite-lhe tirar partido de um conjunto de funcionalidades mais completo para definir, proteger, gerir e rentabilizar as suas APIs baseadas em Funções. Para obter mais informações, veja Gestão de API integração. Para saber como reativar o suporte de proxies nas Funções versão 4.x, veja Reativar proxies em Funções v4.x.
O registo no Armazenamento do Azure com o AzureWebJobsDashboard já não é suportado no 4.x. Em vez disso, deve utilizar o Application Insights. (#1923)
Funções do Azure 4.x impõe agora requisitos mínimos de versão para extensões. Atualize para a versão mais recente das extensões afetadas. Para non-.NET idiomas, atualize para a versão 2.x ou posterior do pacote de extensões. (#1987)
Os tempos limite predefinidos e máximos são agora aplicados em 4.x para aplicações de funções em execução no Linux num plano de Consumo. (#1915)
Funções do Azure 4.x utiliza Azure.Identity e Azure.Security.KeyVault.Secrets para o fornecedor de Key Vault e preteriu a utilização de Microsoft.Azure.KeyVault. Para obter mais informações sobre como configurar as definições da aplicação de funções, veja a opção Key Vault em Repositórios Secretos. (#2048)
As aplicações de funções que partilham contas de armazenamento não iniciam agora quando os IDs de anfitrião são os mesmos. Para obter mais informações, veja Considerações sobre o ID do Anfitrião. (#2049)

Funções do Azure 4.x suporta aplicações .NET 6 no processo e isoladas.
InvalidHostServicesException é agora um erro fatal. (#2045)
EnableEnhancedScopes está ativado por predefinição. (#1954)
Remover HttpClient como um serviço registado. (#1911)

Utilize um carregador de classe única no Java 11. (#1997)
Pare de carregar jars de trabalho em Java 8. (#1991)

Node.js versões 10 e 12 não são suportadas no Funções do Azure 4.x. (#1999)
A serialização de saída em aplicações Node.js foi atualizada para resolver inconsistências anteriores. (#2007)

A contagem de threads predefinida foi atualizada. As funções que não são seguras para threads ou que têm uma utilização de memória elevada podem ser afetadas. (#1962)

O Python 3.6 não é suportado no Funções do Azure 4.x. (#1999)
A transferência de memória partilhada está ativada por predefinição. (#1973)
A contagem de threads predefinida foi atualizada. As funções que não são seguras para threads ou que têm uma utilização de memória elevada podem ser afetadas. (#1962)

Passos seguintes

Saiba mais sobre as versões das Funções

Migrar aplicações da versão 3.x das Funções do Azure para a versão 4.x

Escolha o seu .NET de destino

Prepare para a migração

Executar o validador de pré-atualização

Identificar aplicações de funções a atualizar

Atualizar o projeto local

Ficheiro .csproj

ficheiro program.cs

ficheiro local.settings.json

Alterações ao espaço de nomes

Alterações ao nome da classe

Modelo de acionador HTTP

Atualizar a aplicação de funções no Azure

Atualizar sem blocos

Atualizar com blocos

Atualização padrão

Atualização mínima do tempo de inatividade

Alterações interruptivas entre 3.x e 4.x

Runtime

Passos seguintes

Recursos adicionais

Recursos adicionais