Desenvolver funções de biblioteca de classes C# com Funções do Azure

  • Artigo

Este artigo é uma introdução ao desenvolvimento de Funções do Azure com C# em bibliotecas de classes .NET.

Importante

Este artigo suporta funções de biblioteca de classes .NET que são executadas no processo com o runtime. As funções C# também podem ficar fora do processo e isoladas do runtime das Funções. O modelo de processo de trabalho isolado é a única forma de executar versões não LTS de aplicações .NET e .NET Framework nas versões atuais do runtime das Funções. Para saber mais, veja Funções de processo de trabalho isoladas do .NET. Para obter uma comparação abrangente entre o processo de trabalho isolado e as Funções .NET em processo, veja Diferenças entre o processo em curso e o processo de trabalho isolado .NET Funções do Azure.

Enquanto programador de C#, também poderá estar interessado num dos seguintes artigos:

Introdução Conceitos Aprendizagem/exemplos guiados

Funções do Azure suporta linguagens de programação de scripts C# e C#. Se estiver à procura de orientações sobre como utilizar C# no portal do Azure, consulte Referência para programadores de scripts C# (.csx).

Versões suportadas

As versões do runtime das Funções funcionam com versões específicas do .NET. Para saber mais sobre as versões das Funções, veja Descrição geral Funções do Azure versões de runtime. O suporte da versão depende se as funções são executadas no processo ou num processo de trabalho isolado.

Nota

Para saber como alterar a versão do runtime das Funções utilizada pela sua aplicação de funções, consulte Ver e atualizar a versão atual do runtime.

A tabela seguinte mostra o nível mais elevado de .NET Core ou .NET Framework que podem ser utilizados com uma versão específica das Funções.

Versão do runtime das funções Em processo
(Biblioteca de classes.NET)		 Processo de trabalho isolado
(.NET Isolado)
Funções 4.x .NET 6.0 .NET 6.0
.NET 7.0 (GA)1
.NET Framework 4.8 (GA)1
Funções 1.x .NET Framework 4.8 n/a

1 O processo de compilação também requer o SDK .NET 6.

Para obter as últimas notícias sobre Funções do Azure lançamentos, incluindo a remoção de versões secundárias mais antigas específicas, monitorize Serviço de Aplicações do Azure anúncios.

Projeto de biblioteca de classes de funções

No Visual Studio, o modelo de projeto Funções do Azure cria um projeto de biblioteca de classes C# que contém os seguintes ficheiros:

Quando cria o projeto, é gerada uma estrutura de pastas semelhante ao seguinte exemplo no diretório de saída da compilação:

<framework.version>
 | - bin
 | - MyFirstFunction
 | | - function.json
 | - MySecondFunction
 | | - function.json
 | - host.json

Este diretório é o que é implementado na sua aplicação de funções no Azure. As extensões de enlace necessárias na versão 2.x do runtime das Funções são adicionadas ao projeto como pacotes NuGet.

Importante

O processo de compilação cria um ficheiro function.json para cada função. Este ficheiro function.json não deve ser editado diretamente. Não pode alterar a configuração de enlace nem desativar a função ao editar este ficheiro. Para saber como desativar uma função, veja Como desativar funções.

Métodos reconhecidos como funções

Numa biblioteca de classes, uma função é um método com um FunctionName atributo de acionador e , conforme mostrado no exemplo seguinte:

public static class SimpleExample
{
    [FunctionName("QueueTrigger")]
    public static void Run(
        [QueueTrigger("myqueue-items")] string myQueueItem, 
        ILogger log)
    {
        log.LogInformation($"C# function processed: {myQueueItem}");
    }
}

O FunctionName atributo marca o método como um ponto de entrada de função. O nome tem de ser exclusivo num projeto, começar com uma letra e conter apenas letras, números, _e -, até 127 carateres de comprimento. Os modelos de projeto criam frequentemente um método chamado Run, mas o nome do método pode ser qualquer nome de método C# válido. O exemplo acima mostra um método estático a ser utilizado, mas as funções não são necessárias para serem estáticas.

O atributo de acionador especifica o tipo de acionador e vincula os dados de entrada a um parâmetro de método. A função de exemplo é acionada por uma mensagem de fila e a mensagem de fila é transmitida ao método no myQueueItem parâmetro .

Parâmetros de assinatura do método

A assinatura do método pode conter parâmetros diferentes dos utilizados com o atributo de acionador. Eis alguns dos outros parâmetros que pode incluir:

A ordem dos parâmetros na assinatura de função não importa. Por exemplo, pode colocar parâmetros de acionador antes ou depois de outros enlaces e pode colocar o parâmetro do logger antes ou depois dos parâmetros de acionador ou enlace.

Enlaces de saída

Uma função pode ter zero ou vários enlaces de saída definidos através de parâmetros de saída.

O exemplo seguinte modifica o anterior ao adicionar um enlace de fila de saída com o nome myQueueItemCopy. A função escreve o conteúdo da mensagem que aciona a função para uma nova mensagem numa fila diferente.

public static class SimpleExampleWithOutput
{
    [FunctionName("CopyQueueMessage")]
    public static void Run(
        [QueueTrigger("myqueue-items-source")] string myQueueItem, 
        [Queue("myqueue-items-destination")] out string myQueueItemCopy,
        ILogger log)
    {
        log.LogInformation($"CopyQueueMessage function processed: {myQueueItem}");
        myQueueItemCopy = myQueueItem;
    }
}

Os valores atribuídos aos enlaces de saída são escritos quando a função sai. Pode utilizar mais do que um enlace de saída numa função ao simplesmente atribuir valores a vários parâmetros de saída.

Os artigos de referência de enlace (filas de armazenamento, por exemplo) explicam que tipos de parâmetros pode utilizar com atributos de enlace de acionador, entrada ou saída.

Exemplo de expressões de enlace

O código seguinte obtém o nome da fila para monitorizar a partir de uma definição de aplicação e obtém a hora de criação da mensagem de fila no insertionTime parâmetro .

public static class BindingExpressionsExample
{
    [FunctionName("LogQueueMessage")]
    public static void Run(
        [QueueTrigger("%queueappsetting%")] string myQueueItem,
        DateTimeOffset insertionTime,
        ILogger log)
    {
        log.LogInformation($"Message content: {myQueueItem}");
        log.LogInformation($"Created at: {insertionTime}");
    }
}

Função gerada automaticamente.json

O processo de compilação cria um ficheiro function.json numa pasta de funções na pasta build. Conforme indicado anteriormente, este ficheiro não se destina a ser editado diretamente. Não pode alterar a configuração de enlace nem desativar a função ao editar este ficheiro.

O objetivo deste ficheiro é fornecer informações ao controlador de dimensionamento a utilizar para decisões de dimensionamento no plano de Consumo. Por este motivo, o ficheiro tem apenas informações de acionador e não enlaces de entrada/saída.

O ficheiro function.json gerado inclui uma configurationSource propriedade que indica ao runtime para utilizar atributos .NET para enlaces, em vez da configuração function.json . Eis um exemplo:

{
  "generatedBy": "Microsoft.NET.Sdk.Functions-1.0.0.0",
  "configurationSource": "attributes",
  "bindings": [
    {
      "type": "queueTrigger",
      "queueName": "%input-queue-name%",
      "name": "myQueueItem"
    }
  ],
  "disabled": false,
  "scriptFile": "..\\bin\\FunctionApp1.dll",
  "entryPoint": "FunctionApp1.QueueTrigger.Run"
}

Microsoft.NET.Sdk.Functions

A geração de ficheiros function.json é executada pelo pacote NuGet Microsoft.NET.Sdk.Functions.

O exemplo seguinte mostra as partes relevantes dos .csproj ficheiros que têm arquiteturas de destino diferentes do mesmo Sdk pacote:

<PropertyGroup>
  <TargetFramework>net6.0</TargetFramework>
  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
</ItemGroup>

Entre as dependências do pacote estão acionadores Sdk e enlaces. Um projeto 1.x refere-se a acionadores e enlaces 1.x porque esses acionadores e enlaces visam o .NET Framework, enquanto os acionadores e enlaces 4.x visam o .NET Core.

O Sdk pacote também depende de Newtonsoft.Json e indiretamente do WindowsAzure.Storage. Estas dependências garantem que o projeto utiliza as versões dos pacotes que funcionam com a versão de runtime das Funções que o projeto visa. Por exemplo, Newtonsoft.Json tem a versão 11 para .NET Framework 4.6.1, mas o runtime das Funções que visa .NET Framework 4.6.1 só é compatível com Newtonsoft.Json a versão 9.0.1. Assim, o código de função nesse projeto também tem de utilizar Newtonsoft.Json 9.0.1.

O código fonte para Microsoft.NET.Sdk.Functions está disponível no repositório do GitHub azure-functions-vs-build-sdk.

Versão do runtime local

O Visual Studio utiliza o Funções do Azure Core Tools para executar projetos de Funções no seu computador local. O Core Tools é uma interface de linha de comandos para o runtime das Funções.

Se instalar o Core Tools com o pacote de instalação do Windows (MSI) ou com o npm, isso não afetará a versão do Core Tools utilizada pelo Visual Studio. Para a versão 1.x do runtime das Funções, o Visual Studio armazena versões do Core Tools em %USERPROFILE%\AppData\Local\Azure.Functions.Cli e utiliza a versão mais recente aí armazenada. Para as Funções 4.x, as Ferramentas Principais estão incluídas na extensão ferramentas de Funções do Azure e Web Jobs. Para as Funções 1.x, pode ver que versão está a ser utilizada na saída da consola quando executa um projeto de Funções:

[3/1/2018 9:59:53 AM] Starting Host (HostId=contoso2-1518597420, Version=2.0.11353.0, ProcessId=22020, Debug=False, Attempt=0, FunctionsExtensionVersion=)

ReadyToRun

Pode compilar a sua aplicação de funções como binários ReadyToRun. ReadyToRun é uma forma de compilação antecipada que pode melhorar o desempenho do arranque para ajudar a reduzir o impacto do arranque a frio ao executar num plano de Consumo.

ReadyToRun está disponível no .NET 6 e versões posteriores e requer a versão 4.0 do Funções do Azure runtime.

Para compilar o projeto como ReadyToRun, atualize o ficheiro do projeto ao adicionar os <PublishReadyToRun> elementos e <RuntimeIdentifier> . Segue-se a configuração para publicar numa aplicação de funções do Windows de 32 bits.

<PropertyGroup>
  <TargetFramework>net6.0</TargetFramework>
  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
  <PublishReadyToRun>true</PublishReadyToRun>
  <RuntimeIdentifier>win-x86</RuntimeIdentifier>
</PropertyGroup>

Importante

A partir do .NET 6, foi adicionado suporte para compilação ReadyToRun Composta. Consulte As restrições de arquitetura e plataformas ReadyToRun.

Também pode criar a sua aplicação com ReadyToRun a partir da linha de comandos. Para obter mais informações, veja a opção -p:PublishReadyToRun=true em dotnet publish.

Tipos suportados para enlaces

Cada enlace tem os seus próprios tipos suportados; por exemplo, um atributo de acionador de blobs pode ser aplicado a um parâmetro de cadeia, a um parâmetro POCO, a um CloudBlockBlob parâmetro ou a qualquer outro tipo suportado. O artigo de referência de enlace para enlaces de blobs lista todos os tipos de parâmetros suportados. Para obter mais informações, veja Acionadores e enlaces e os documentos de referência de enlace para cada tipo de enlace.

Dica

Se planear utilizar os enlaces HTTP ou WebHook, planeie evitar o esgotamento das portas que pode ser causado por instâncias impróprias de HttpClient. Para obter mais informações, veja Como gerir ligações no Funções do Azure.

Enlace ao valor de retorno do método

Pode utilizar um valor de retorno de método para um enlace de saída ao aplicar o atributo ao valor de retorno do método. Para obter exemplos, veja Acionadores e enlaces.

Utilize o valor devolvido apenas se uma execução de função com êxito resultar sempre num valor devolvido para passar para o enlace de saída. Caso contrário, utilize ICollector ou IAsyncCollector, conforme mostrado na secção seguinte.

Escrever vários valores de saída

Para escrever vários valores num enlace de saída ou se uma invocação de função bem-sucedida não resultar em nada para passar para o enlace de saída, utilize os ICollector tipos ou IAsyncCollector . Estes tipos são coleções só de escrita que são escritas no enlace de saída quando o método é concluído.

Este exemplo escreve várias mensagens de fila na mesma fila com ICollector:

public static class ICollectorExample
{
    [FunctionName("CopyQueueMessageICollector")]
    public static void Run(
        [QueueTrigger("myqueue-items-source-3")] string myQueueItem,
        [Queue("myqueue-items-destination")] ICollector<string> myDestinationQueue,
        ILogger log)
    {
        log.LogInformation($"C# function processed: {myQueueItem}");
        myDestinationQueue.Add($"Copy 1: {myQueueItem}");
        myDestinationQueue.Add($"Copy 2: {myQueueItem}");
    }
}

Assíncrono

Para tornar uma função assíncrona, utilize a async palavra-chave e devolva um Task objeto.

public static class AsyncExample
{
    [FunctionName("BlobCopy")]
    public static async Task RunAsync(
        [BlobTrigger("sample-images/{blobName}")] Stream blobInput,
        [Blob("sample-images-copies/{blobName}", FileAccess.Write)] Stream blobOutput,
        CancellationToken token,
        ILogger log)
    {
        log.LogInformation($"BlobCopy function processed.");
        await blobInput.CopyToAsync(blobOutput, 4096, token);
    }
}

Não pode utilizar out parâmetros em funções assíncronas. Para enlaces de saída, utilize antes o valor de retorno da função ou um objeto recoletor .

Tokens de cancelamento

Uma função pode aceitar um parâmetro CancellationToken , que permite ao sistema operativo notificar o código quando a função está prestes a ser terminada. Pode utilizar esta notificação para se certificar de que a função não termina inesperadamente de uma forma que deixe os dados num estado inconsistente.

Considere o caso quando tiver uma função que processa mensagens em lotes. A seguinte função acionada por Azure Service Bus processa uma matriz de objetos de Mensagem, que representa um lote de mensagens recebidas a serem processadas por uma invocação de função específica:

using Microsoft.Azure.ServiceBus;
using System.Threading;

namespace ServiceBusCancellationToken
{
    public static class servicebus
    {
        [FunctionName("servicebus")]
        public static void Run([ServiceBusTrigger("csharpguitar", Connection = "SB_CONN")]
               Message[] messages, CancellationToken cancellationToken, ILogger log)
        {
            try
            { 
                foreach (var message in messages)
                {
                    if (cancellationToken.IsCancellationRequested)
                    {
                        log.LogInformation("A cancellation token was received. Taking precautionary actions.");
                        //Take precautions like noting how far along you are with processing the batch
                        log.LogInformation("Precautionary activities --complete--.");
                        break;
                    }
                    else
                    {
                        //business logic as usual
                        log.LogInformation($"Message: {message} was processed.");
                    }
                }
            }
            catch (Exception ex)
            {
                log.LogInformation($"Something unexpected happened: {ex.Message}");
            }
        }
    }
}

Registo

No código da função, pode escrever resultados em registos que aparecem como rastreios no Application Insights. A forma recomendada de escrever nos registos é incluir um parâmetro do tipo ILogger, normalmente denominado log. Versão 1.x do runtime de Funções utilizado TraceWriter, que também escreve no Application Insights, mas não suporta o registo estruturado. Não utilize Console.Write para escrever os seus registos, uma vez que estes dados não são capturados pelo Application Insights.

ILogger

Na definição da função, inclua um parâmetro ILogger , que suporta o registo estruturado.

Com um ILogger objeto, chama Log<level>métodos de extensão no ILogger para criar registos. O código seguinte escreve registos Information com a categoria Function.<YOUR_FUNCTION_NAME>.User.:

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, ILogger logger)
{
    logger.LogInformation("Request for item with key={itemKey}.", id);

Para saber mais sobre como as Funções implementam ILoggero , veja Collecting telemetry data (Recolher dados telemétricos). As categorias com prefixo assumem Function que está a utilizar uma ILogger instância. Se optar por utilizar um ILogger<T>, o nome da categoria poderá basear-se em T.

Registos estruturados

A ordem dos marcadores de posição, não os respetivos nomes, determina os parâmetros que são utilizados na mensagem de registo. Suponha que tem o seguinte código:

string partitionKey = "partitionKey";
string rowKey = "rowKey";
logger.LogInformation("partitionKey={partitionKey}, rowKey={rowKey}", partitionKey, rowKey);

Se mantiver a mesma cadeia de mensagem e inverter a ordem dos parâmetros, o texto da mensagem resultante terá os valores nos locais errados.

Os marcadores de posição são processados desta forma para que possa efetuar o registo estruturado. O Application Insights armazena os pares nome-valor do parâmetro e a cadeia de mensagem. O resultado é que os argumentos da mensagem tornam-se campos nos quais pode consultar.

Se a chamada do método logger for semelhante ao exemplo anterior, pode consultar o campo customDimensions.prop__rowKey. O prop__ prefixo é adicionado para garantir que não existem colisões entre os campos que o runtime adiciona e os campos que o código da função adiciona.

Também pode consultar na cadeia de mensagem original ao referenciar o campo customDimensions.prop__{OriginalFormat}.

Eis um exemplo de representação JSON de customDimensions dados:

{
  "customDimensions": {
    "prop__{OriginalFormat}":"C# Queue trigger function processed: {message}",
    "Category":"Function",
    "LogLevel":"Information",
    "prop__message":"c9519cbf-b1e6-4b9b-bf24-cb7d10b1bb89"
  }
}

Registar telemetria personalizada

Existe uma versão específica das Funções do SDK do Application Insights que pode utilizar para enviar dados telemétricos personalizados das suas funções para o Application Insights: Microsoft.Azure.WebJobs.Logging.ApplicationInsights. Utilize o seguinte comando da linha de comandos para instalar este pacote:

dotnet add package Microsoft.Azure.WebJobs.Logging.ApplicationInsights --version <VERSION>

Neste comando, substitua por <VERSION> uma versão deste pacote que suporte a sua versão instalada do Microsoft.Azure.WebJobs.

Os seguintes exemplos de C# utilizam a API de telemetria personalizada. O exemplo é para uma biblioteca de classes .NET, mas o código do Application Insights é o mesmo para o script C#.

A versão 2.x e versões posteriores do runtime utilizam funcionalidades mais recentes no Application Insights para correlacionar automaticamente a telemetria com a operação atual. Não é necessário definir manualmente a operação Id, ParentIdou Name campos.

using System;
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 Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
using System.Linq;

namespace functionapp0915
{
    public class HttpTrigger2
    {
        private readonly TelemetryClient telemetryClient;

        /// Using dependency injection will guarantee that you use the same configuration for telemetry collected automatically and manually.
        public HttpTrigger2(TelemetryConfiguration telemetryConfiguration)
        {
            this.telemetryClient = new TelemetryClient(telemetryConfiguration);
        }

        [FunctionName("HttpTrigger2")]
        public Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = null)]
            HttpRequest req, ExecutionContext context, ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");
            DateTime start = DateTime.UtcNow;

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

            // Write an event to the customEvents table.
            var evt = new EventTelemetry("Function called");
            evt.Context.User.Id = name;
            this.telemetryClient.TrackEvent(evt);

            // Generate a custom metric, in this case let's use ContentLength.
            this.telemetryClient.GetMetric("contentLength").TrackValue(req.ContentLength);

            // Log a custom dependency in the dependencies table.
            var dependency = new DependencyTelemetry
            {
                Name = "GET api/planets/1/",
                Target = "swapi.co",
                Data = "https://swapi.co/api/planets/1/",
                Timestamp = start,
                Duration = DateTime.UtcNow - start,
                Success = true
            };
            dependency.Context.User.Id = name;
            this.telemetryClient.TrackDependency(dependency);

            return Task.FromResult<IActionResult>(new OkResult());
        }
    }
}

Neste exemplo, os dados de métricas personalizadas são agregados pelo anfitrião antes de serem enviados para a tabela customMetrics. Para saber mais, veja a documentação GetMetric no Application Insights.

Ao executar localmente, tem de adicionar a APPINSIGHTS_INSTRUMENTATIONKEY definição, com a chave do Application Insights, ao ficheiro local.settings.json .

Não chame TrackRequest ou StartOperation<RequestTelemetry> porque verá pedidos duplicados para uma invocação de função. O runtime das Funções controla automaticamente os pedidos.

Não defina telemetryClient.Context.Operation.Id. Esta definição global causa uma correlação incorreta quando muitas funções estão em execução em simultâneo. Em vez disso, crie uma nova instância de telemetria (DependencyTelemetry, EventTelemetry) e modifique a respetiva Context propriedade. Em seguida, transmita a instância de telemetria para o método correspondente Track em TelemetryClient (TrackDependency(), TrackEvent(), TrackMetric()). Este método garante que a telemetria tem os detalhes de correlação corretos para a invocação da função atual.

Testar funções

Os artigos seguintes mostram como executar uma função de biblioteca de classeS C# no processo localmente para fins de teste:

Variáveis de ambiente

Para obter uma variável de ambiente ou um valor de definição de aplicação, utilize System.Environment.GetEnvironmentVariable, conforme mostrado no seguinte exemplo de código:

public static class EnvironmentVariablesExample
{
    [FunctionName("GetEnvironmentVariables")]
    public static void Run([TimerTrigger("0 */5 * * * *")]TimerInfo myTimer, ILogger log)
    {
        log.LogInformation($"C# Timer trigger function executed at: {DateTime.Now}");
        log.LogInformation(GetEnvironmentVariable("AzureWebJobsStorage"));
        log.LogInformation(GetEnvironmentVariable("WEBSITE_SITE_NAME"));
    }

    private static string GetEnvironmentVariable(string name)
    {
        return name + ": " +
            System.Environment.GetEnvironmentVariable(name, EnvironmentVariableTarget.Process);
    }
}

As definições da aplicação podem ser lidas a partir de variáveis de ambiente ao desenvolver localmente e ao executar no Azure. Ao desenvolver localmente, as definições da aplicação provêm da Values coleção no ficheiro local.settings.json . Em ambos os ambientes, local e Azure, GetEnvironmentVariable("<app setting name>") obtém o valor da definição da aplicação nomeada. Por exemplo, quando estiver a executar localmente, "O Meu Nome do Site" será devolvido se o ficheiro local.settings.json contiver { "Values": { "WEBSITE_SITE_NAME": "My Site Name" } }.

A propriedade System.Configuration.ConfigurationManager.AppSettings é uma API alternativa para obter valores de definição de aplicação, mas recomendamos que utilize GetEnvironmentVariable como mostrado aqui.

Enlace no runtime

Em C# e noutros idiomas .NET, pode utilizar um padrão de enlace imperativo , em oposição aos enlaces declarativos em atributos. O enlace imperativo é útil quando os parâmetros de enlace têm de ser calculados no runtime e não no tempo de conceção. Com este padrão, pode vincular-se aos enlaces de entrada e saída suportados no código de função.

Defina um enlace imperativo da seguinte forma:

  • Não inclua um atributo na assinatura de função para os enlaces imperativos pretendidos.

  • Transmita um parâmetro Binder binder de entrada ou IBinder binder.

  • Utilize o seguinte padrão C# para efetuar o enlace de dados.

    using (var output = await binder.BindAsync<T>(new BindingTypeAttribute(...)))
{
    ...
}

    BindingTypeAttribute é o atributo .NET que define o enlace e T é um tipo de entrada ou saída suportado por esse tipo de enlace. T não pode ser um tipo de out parâmetro (como out JObject). Por exemplo, o enlace de saída da tabela aplicações móveis suporta seis tipos de saída, mas só pode utilizar ICollector<T> ou IAsyncCollector<T> com enlace imperativo.

Exemplo de atributo único

O código de exemplo seguinte cria um enlace de saída do blob de armazenamento com o caminho do blob definido no tempo de execução e, em seguida, escreve uma cadeia no blob.

public static class IBinderExample
{
    [FunctionName("CreateBlobUsingBinder")]
    public static void Run(
        [QueueTrigger("myqueue-items-source-4")] string myQueueItem,
        IBinder binder,
        ILogger log)
    {
        log.LogInformation($"CreateBlobUsingBinder function processed: {myQueueItem}");
        using (var writer = binder.Bind<TextWriter>(new BlobAttribute(
                    $"samples-output/{myQueueItem}", FileAccess.Write)))
        {
            writer.Write("Hello World!");
        };
    }
}

BlobAttribute define o enlace de entrada ou saída do blob de Armazenamento e o TextWriter é um tipo de enlace de saída suportado.

Exemplo de múltiplos atributos

O exemplo anterior obtém a definição da aplicação para a cadeia de ligação da conta de armazenamento principal da aplicação de funções (que é AzureWebJobsStorage). Pode especificar uma definição de aplicação personalizada a utilizar para a conta de Armazenamento ao adicionar o StorageAccountAttribute e ao transmitir a matriz de atributos para BindAsync<T>(). Utilize um Binder parâmetro, não IBinder. Por exemplo:

public static class IBinderExampleMultipleAttributes
{
    [FunctionName("CreateBlobInDifferentStorageAccount")]
    public async static Task RunAsync(
            [QueueTrigger("myqueue-items-source-binder2")] string myQueueItem,
            Binder binder,
            ILogger log)
    {
        log.LogInformation($"CreateBlobInDifferentStorageAccount function processed: {myQueueItem}");
        var attributes = new Attribute[]
        {
        new BlobAttribute($"samples-output/{myQueueItem}", FileAccess.Write),
        new StorageAccountAttribute("MyStorageAccount")
        };
        using (var writer = await binder.BindAsync<TextWriter>(attributes))
        {
            await writer.WriteAsync("Hello World!!");
        }
    }
}

Acionadores e enlaces

Esta tabela mostra os enlaces suportados nas versões principais do Funções do Azure runtime:

Tipo 1.x 2.x e superior1 Acionador Input Saída
Armazenamento de blobs ✔ ✔ ✔ ✔ ✔
BD do Cosmos para o Azure ✔ ✔ ✔ ✔ ✔
SQL do Azure ✔ ✔ ✔ ✔
Dapr3 ✔ ✔ ✔ ✔
Event Grid ✔ ✔ ✔ ✔
Hubs de Eventos ✔ ✔ ✔ ✔
Webhooks HTTP & ✔ ✔ ✔ ✔
Hub IoT ✔ ✔ ✔
Kafka2 ✔ ✔ ✔
Aplicações Móveis ✔ ✔ ✔
Hubs de Notificação ✔ ✔
Armazenamento de filas ✔ ✔ ✔ ✔
RabbitMQ2 ✔ ✔ ✔
SendGrid ✔ ✔ ✔
Service Bus ✔ ✔ ✔ ✔
SignalR ✔ ✔ ✔ ✔
Armazenamento de tabelas ✔ ✔ ✔ ✔
Temporizador ✔ ✔ ✔
Twilio ✔ ✔ ✔

1 A partir do runtime da versão 2.x, todos os enlaces exceto HTTP e Temporizador têm de estar registados. Veja Registar extensões de enlace.

2 Os acionadores não são suportados no plano de Consumo. Requer acionadores orientados por runtime.

3 Suportado apenas no Kubernetes, IoT Edge e noutros modos autoalojados.

Passos seguintes

Saiba mais sobre acionadores e enlaces

Saiba mais sobre as melhores práticas para Funções do Azure