Migrar aplicativos do Azure Functions versão 1.x para a versão 4.x

  • Artigo
  • 24 minutos para o fim da leitura

Importante

Não há suporte para Java na versão 1.x do runtime do Azure Functions. Provavelmente seria melhor migrar seu aplicativo Java da versão 3.x para a versão 4.x. Se você estiver migrando um aplicativo de funções versão 1.x, selecione acima C# ou JavaScript.

Importante

Não há suporte para TypeScript na versão 1.x do runtime do Azure Functions. Provavelmente seria melhor migrar seu aplicativo TypeScript da versão 3.x para a versão 4.x. Se você estiver migrando um aplicativo de funções versão 1.x, selecione acima C# ou JavaScript.

Importante

Não há suporte para PowerShell na versão 1.x do runtime do Azure Functions. Provavelmente seria melhor migrar seu aplicativo PowerShell da versão 3.x para a versão 4.x. Se você estiver migrando um aplicativo de funções versão 1.x, selecione acima C# ou JavaScript.

Importante

Não há suporte par Python na versão 1.x do runtime do Azure Functions. Provavelmente seria melhor migrar seu aplicativo Python da versão 3.x para a versão 4.x. Se você estiver migrando um aplicativo de funções versão 1.x, selecione acima C# ou JavaScript.

Se você estiver executando na versão 1.x do runtime do Azure Functions, é provável que seja porque seu aplicativo C# precisa do .NET Framework 2.1. Agora, a versão 4.x do runtime permite que você execute aplicativos do .NET Framework 4.8. Neste ponto, é aconselhável migrar seus aplicativos de funções versão 1.x para serem executados na versão 4.x. Para saber mais sobre as versões de runtime do Functions, confira Visão geral de versões do runtime do Azure Functions.

Migrar um aplicativo de funções C# da versão 1.x para a versão 4.x do runtime do Functions exige que você faça alterações no código do projeto. Muitas dessas alterações são resultado de alterações na linguagem C# e nas APIs do .NET. Os aplicativos JavaScript geralmente não exigem alterações de código para migrar.

Você pode atualizar seu projeto C# para uma das seguintes versões do .NET, todas elas podem ser executadas no Functions versão 4.x:

Versão do .NET Modelo de processo*
.NET 7 Processo de trabalho isolado
.NET 6 Processo de trabalho isolado
.NET 6 Em processo
.NET Framework 4.8 Processo de trabalho isolado

*A execução em processo só tem suporte para versões com LTS (suporte de longo prazo) do .NET. As versões sem LTS e o .NET Framework exigem que você seja executado em um processo de trabalho isolado. Para obter uma comparação de recursos e funcionalidades entre os dois modelos de processo, consulte Diferenças entre .NET de processo de trabalho em processo e isolado do Azure Functions.

Este artigo percorre o processo de migração segura do aplicativo de funções para que seja executado na versão 4.x do runtime do Functions.

Preparar para a migração

Antes de atualizar o aplicativo para a versão 4.x do runtime do Functions, realize as seguintes tarefas:

  • Revise Atualizar arquivos de projeto e decida para qual versão do .NET você deseja migrar. Conclua as etapas para migrar seu projeto local para a versão escolhida do .NET.
  • Conclua as etapas em atualizar arquivos de projeto para migrar seu projeto local para ser executado localmente em uma versão 4.x e uma versão com suporte do Node.js.

  • Após migrar seu projeto local, faça um teste completo do aplicativo no local usando a versão 4.x do Azure Functions Core Tools.

  • Atualize o aplicativo de funções no Azure para a nova versão. Caso você precise minimizar o tempo de inatividade, considere o uso de um slot de preparo para testar e verificar seu aplicativo migrado no Azure na nova versão de runtime. Em seguida, você pode implantar o aplicativo com as configurações de versão atualizadas no slot de produção. Para saber mais, confira Migrar usando slots.

  • Publicou novamente seu projeto migrado para o aplicativo de funções atualizado. Quando você usa o Visual Studio para publicar um projeto versão 4.x em um aplicativo de funções existente com uma versão inferior, é solicitado que você permita que o Visual Studio atualize o aplicativo de funções para a versão 4.x durante a implantação. Essa atualização usa o mesmo processo definido em Migrar sem slots.
  • Republicou seu projeto migrado para o aplicativo de funções atualizado.
  • Considere usar um slot de preparo para testar e verificar o aplicativo no Azure na nova versão do runtime. Em seguida, você pode implantar o aplicativo com as configurações de versão atualizadas no slot de produção. Para saber mais, confira Migrar usando slots.

Atualizar seus arquivos de projeto

As seções a seguir descrevem as atualizações que você deve fazer em seus arquivos de projeto C# para poder executar em uma das versões com suporte do .NET na versão 4.x do Functions. As atualizações mostradas são comuns à maioria dos projetos. O código do projeto pode exigir atualizações ignoradas neste artigo, especialmente ao usar pacotes NuGet personalizados.

Escolha a guia que corresponde à versão de destino do .NET e ao modelo de processo desejado (processo de trabalho em processo ou isolado).

Arquivo .csproj

O exemplo a seguir é um arquivo de projeto .csproj executado na versão 1.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <AzureFunctionsVersion>v1</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
  </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>

Use um dos procedimentos a seguir para atualizar esse arquivo XML para ser executado na versão 4.x do Functions:

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

  1. Altere o valor de PropertyGroup.AzureFunctionsVersion para v4.

  2. Adicione o seguinte elemento OutputType ao PropertyGroup:

    <OutputType>Exe</OutputType>

  3. Substituir o ItemGroup existente.PackageReference pelo 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>

  4. Adicione o ItemGroup novo a seguir:

    <ItemGroup>
  <Folder Include="Properties\" />
</ItemGroup>

Depois que você fizer essas alterações, o projeto atualizado será semelhante ao seguinte exemplo:


<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
  </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>
    <Folder Include="Properties\" />
  </ItemGroup>
</Project>

Arquivo program.cs

Na maioria dos casos, a migração exige que você adicione o seguinte arquivo program.cs ao seu projeto:

using Microsoft.Extensions.Hosting;
using Microsoft.Azure.Functions.Worker;

namespace Company.FunctionApp
{
    internal class Program
    {
        static void Main(string[] args)
        {
            FunctionsDebugger.Enable();

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

            host.Run();
        }
    }
}

Arquivo host.json

As configurações no arquivo host.json são aplicáveis no nível do aplicativo de funções, localmente e no Azure. Na versão 1.x, o arquivo host.json está vazio ou contém algumas configurações que se aplicam a todas as funções no aplicativo de funções. Para obter mais informações, confira Host.json v1. Se o arquivo host.json tiver valores de configuração, revise o formato host.json v2 para ver se há alterações.

Para executar na versão 4.x, você deve adicionar "version": "2.0" ao arquivo host.json. Você também deve considerar adicionar logging à sua configuração, como nos seguintes exemplos:

{
    "version": "2.0",
    "logging": {
        "applicationInsights": {
            "samplingSettings": {
                "isEnabled": true,
                "excludedTypes": "Request"
            }
        }
    }
}

Arquivo local.settings.json

O arquivo local.settings.json só é usado durante a execução local. Para obter informações, confira Arquivo de configurações local. Na versão 1.x, o arquivo local.settings.json tem apenas dois valores necessários:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "AzureWebJobsDashboard": "AzureWebJobsStorageConnectionStringValue"
    }
}

Ao atualizar para a versão 4.x, verifique se o arquivo local.settings.json tem pelo menos os seguintes elementos:

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

Alterações de namespace

As funções C# executadas em um processo de trabalho isolado usam bibliotecas em um namespace diferente daquelas bibliotecas usadas na versão 1.x. As funções em processo usam bibliotecas no mesmo namespace.

As bibliotecas de versão 1.x e em processo geralmente estão no namespace Microsoft.Azure.WebJobs.*. Os aplicativos de funções de processo de trabalho isolado usam bibliotecas no namespace Microsoft.Azure.Functions.Worker.*. Veja o efeito dessas alterações de namespace nas instruções using nos exemplos de modelos de gatilho HTTP a seguir.

Alterações de nome de classe

Algumas classes de chave alteraram os nomes entre a versão 1.x e a versão 4.x. Essas alterações são resultado de alterações nas APIs do .NET ou em diferenças entre o processo de trabalho em processo e isolado. A tabela a seguir indica essas classes de chave do .NET usadas pelo Azure Functions que foram alteradas após a versão 1.x:

Versão 1.x .NET Framework 4.8
FunctionName (atributo) Function (atributo)
TraceWriter ILogger
HttpRequestMessage HttpRequestData
HttpResonseMessage HttpResonseData

Também pode haver diferenças de nome da classe nas associações. Para saber mais, confira os artigos de referência das associações específicas.

Modelo de gatilho HTTP

A maioria das alterações de código entre a versão 1.x e a versão 4.x pode ser vista em funções disparadas por HTTP. O modelo de gatilho HTTP para a versão 1.x é semelhante ao exemplo a seguir:

using System.Linq;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Azure.WebJobs.Host;

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

            // parse query parameter
            string name = req.GetQueryNameValuePairs()
                .FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
                .Value;

            if (name == null)
            {
                // Get request body
                dynamic data = await req.Content.ReadAsAsync<object>();
                name = data?.name;
            }

            return name == null
                ? req.CreateResponse(HttpStatusCode.BadRequest, 
                    "Please pass a name on the query string or in the request body")
                : req.CreateResponse(HttpStatusCode.OK, "Hello " + name);
        }
    }
}

Na versão 4.x, o modelo de gatilho HTTP é semelhante ao seguinte exemplo:

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

Atualizar seus arquivos de projeto

Para atualizar o projeto para o Azure Functions 4.x:

  1. Atualize a instalação local do Azure Functions Core Tools para a versão 4.x.

  2. Mover para uma das versões do Node.js com suporte na versão 4.x.

  3. Adicione elementos version e extensionBundle ao host.json para que ele se pareça com o exemplo a seguir:

    {
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[3.3.0, 4.0.0)"
    }
}

    O elemento extensionBundle é necessário porque, após a versão 1.x, as associações são mantidas como pacotes externos. Para obter mais informações, consulte Pacotes de extensão.

  4. Atualize o arquivo local.settings.json para que ele tenha pelo menos elementos a seguir:

    {
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "node"
    }
}

    A configuração AzureWebJobsStorage pode ser o emulador de armazenamento do Azurite ou uma conta de armazenamento do Azure de fato. Para obter mais informações, confira Emulador de armazenamento local.

Atualizar seu aplicativo de funções no Azure

Você precisa atualizar o runtime do host do aplicativo de funções no Azure para a versão 4.x antes de publicar seu projeto migrado. A versão de runtime usada pelo host do Functions é controlada pela configuração de aplicativo FUNCTIONS_EXTENSION_VERSION, mas em alguns casos outras configurações também precisam ser atualizadas. As alterações de código e as alterações nas configurações de aplicativo exigem que o aplicativo de funções seja reiniciado.

A maneira mais fácil é a atualização sem slots e a nova publicação do projeto de aplicativo. Minimize também o tempo de inatividade no aplicativo e simplifique a reversão com a atualização por meio de slots.

Atualização sem slots

A maneira mais simples de atualizar para a v4.x é definir a configuração de aplicativo FUNCTIONS_EXTENSION_VERSION como ~4 em seu aplicativo de funções no Azure. Siga um procedimento diferente em um site com slots.

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

Durante a atualização, você também precisa definir outra configuração, que é diferente entre o Windows e o Linux.

Ao executar no Windows, você também precisa habilitar 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 aplicativos de funções em qualquer idioma em execução no Windows.

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

Agora você pode publicar novamente seu projeto de aplicativo que foi migrado para ser executado na versão 4.x.

Atualização por meio de slots

Usar slots de implantação é uma boa maneira de migrar seu aplicativo de funções para o runtime v4.x de uma versão anterior. Usando um slot de preparo, você pode executar o aplicativo na nova versão do runtime no slot de preparo e alternar para a produção após a verificação. Os slots também fornecem uma maneira de minimizar o tempo de inatividade durante a atualização. Se precisar minimizar o tempo de inatividade, siga as etapas em Atualização com tempo de inatividade mínimo.

Depois de verificar o aplicativo no slot atualizado, você pode trocar o aplicativo e as novas configurações da versão para produção. Essa troca requer a configuração WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 no slot de produção. A maneira como você adiciona essa configuração afeta a quantidade de tempo de inatividade necessário para a atualização.

Atualização padrão

Se o aplicativo de funções habilitado para slots puder lidar com o tempo de inatividade de uma reinicialização completa, você poderá atualizar a configuração WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS diretamente no slot de produção. Como alterar essa configuração diretamente no slot de produção causa uma reinicialização que afeta a disponibilidade, considere fazer a alteração em um momento de tráfego reduzido. Em seguida, você pode trocar pela versão atualizada do slot de preparo.

No momento, o cmdlet do PowerShell Update-AzFunctionAppSetting não dá suporte a slots. Você precisa usar a CLI do Azure ou o portal do Azure.

  1. Use o seguinte comando para definir WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 no slot 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 do aplicativo de funções e <RESOURCE_GROUP_NAME> pelo nome do grupo de recursos. Esse comando faz com que o aplicativo em execução no slot de produção seja reiniciado.

  2. Use o seguinte comando para também definir WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS no slot de preparo:

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

  3. Use o seguinte comando para alterar FUNCTIONS_EXTENSION_VERSION e atualizar o slot de preparo 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>

  4. A versão 4.x do runtime do Functions exige o .NET 6 no Windows. No Linux, os aplicativos .NET também devem fazer upgrade para o .NET 6. Use o comando a seguir para que o runtime possa ser executado no .NET 6:

    Ao executar no Windows, você também precisa habilitar 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 aplicativos de funções em qualquer idioma em execução no Windows.

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

  5. Se o projeto de código exigiu alguma atualização para ser executado na versão 4.x, implante essas atualizações no slot de preparo agora.

  6. Confirme se o aplicativo de funções é executado corretamente no ambiente de preparo atualizado antes da troca.

  7. Use o seguinte comando para colocar o slot de preparo atualizado na produção:

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

Atualização com tempo de inatividade mínimo

Para minimizar o tempo de inatividade em seu aplicativo de produção, coloque a configuração WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS do slot de preparo para a produção. Depois disso, você pode trocar pela versão atualizada de um slot de preparo pré-aquecido.

  1. Use o seguinte comando para definir WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 no slot de preparo:

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

  2. Use os comandos a seguir para colocar o slot com a nova configuração em produção e, ao mesmo tempo, restaurar a configuração da versão no slot de preparo.

    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>

    Você poderá ver erros do slot de preparo durante o período entre a troca e a versão do runtime que está sendo restaurada no preparo. Isso pode acontecer porque ter WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 apenas no preparo durante uma troca remove a configuração FUNCTIONS_EXTENSION_VERSION no preparo. Sem a configuração da versão, o slot fica em um estado inválido. Atualizar a versão no slot de preparo logo após a troca deve colocar o slot de volta em um estado válido e você pode chamar uma reversão das alterações se necessário. No entanto, qualquer reversão da troca também exige que você remova WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 diretamente da produção antes de trocar de volta para evitar os mesmos erros na produção vistos no preparo. Essa alteração na configuração de produção causaria uma reinicialização.

  3. Use o seguinte comando para definir WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 novamente no slot de preparo:

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

    Neste ponto, ambos os slots têm WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 definido.

  4. Use o seguinte comando para alterar FUNCTIONS_EXTENSION_VERSION e atualizar o slot de preparo 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>

  5. A versão 4.x do runtime do Functions exige o .NET 6 no Windows. No Linux, os aplicativos .NET também devem fazer upgrade para o .NET 6. Use o comando a seguir para que o runtime possa ser executado no .NET 6:

    Ao executar no Windows, você também precisa habilitar 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 aplicativos de funções em qualquer idioma em execução no Windows.

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

  6. Se o projeto de código exigiu alguma atualização para ser executado na versão 4.x, implante essas atualizações no slot de preparo agora.

  7. Confirme se o aplicativo de funções é executado corretamente no ambiente de preparo atualizado antes da troca.

  8. Use o seguinte comando para colocar o slot de preparo atualizado e pré-aquecido na produção:

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

Alterações de comportamento após a versão 1.x

Esta seção detalha as alterações feitas após a versão 1.x em comportamentos de gatilho e de associação, bem como nos principais recursos e comportamentos do Functions.

Alterações nos gatilhos e associações

A partir da versão 2.x, é necessário instalar as extensões de ligações e gatilhos específicos usadas pelas funções em seu aplicativo. A única exceção para isso são os gatilhos de temporizador e HTTP, que não exigem uma extensão. Para obter mais informações, confira Registrar e instalar extensões de associação.

Também há algumas alterações no function.json ou em atributos da função entre as versões. Por exemplo, a propriedade path do Hubs de Eventos agora é eventHubName. Veja a tabela de associação existente para obter links para a documentação de cada associação.

Alterações nos recursos e funcionalidades

Alguns recursos foram removidos, atualizados ou substituídos após a versão 1.x. Esta seção detalha as mudanças aplicadas às versões mais recentes após ter usado a versão 1.x.

As seguintes alterações foram feitas na versão 2.x:

  • As chaves para chamar pontos de extremidade HTTP são sempre armazenadas criptografadas no Armazenamento de Blobs do Azure. Na versão 1.x, as chaves eram armazenadas nos Arquivos do Azure por padrão. Ao atualizar um aplicativo da versão 1.x para a 2.x, os segredos existentes que estão nos Arquivos do Azure serão redefinidos.

  • A versão 2.x do runtime não inclui suporte interno para provedores de webhook. Essa alteração foi feita para melhorar o desempenho. Você ainda pode usar gatilhos HTTP como pontos de extremidade para webhooks.

  • Para melhorar o monitoramento, o painel WebJobs no portal, o qual usou a configuração AzureWebJobsDashboard, é substituído com o Azure Application Insights, que usa a configuração APPINSIGHTS_INSTRUMENTATIONKEY. Para saber mais, consulte Monitorar Azure Functions.

  • Todas as funções em um aplicativo de funções devem compartilhar a mesma linguagem de programação. Quando você cria um aplicativo de funções, você deve escolher para ele uma pilha de runtime. A pilha de runtime é especificada pelo valor FUNCTIONS_WORKER_RUNTIME nas configurações do aplicativo. Esse requisito foi adicionado para melhorar o tempo de inicialização e o volume. Ao desenvolver localmente, você também deve incluir essa configuração no arquivo local.settings.json.

  • O tempo limite padrão para as funções em um plano do Serviço de Aplicativo foi alterado para 30 minutos. Você pode alterar manualmente o tempo limite para ilimitado, usando a configuração functionTimeout em host.json.

  • Restrições de simultaneidade HTTP são implementadas por padrão para funções de plano de consumo, com um padrão de 100 solicitações simultâneas por instância. Você pode alterar esse comportamento na configuração maxConcurrentRequests no arquivo host.json.

  • Devido às limitações do .NET Core, o suporte a funções de script F# (.fsx) foi removido. Funções F# compiladas (.fs) ainda são compatíveis.

  • O formato da URL de webhooks de gatilho da Grade de Eventos foi alterado para seguir este padrão: https://{app}/runtime/webhooks/{triggerName}.

Próximas etapas

Saiba mais sobre as versões do Functions