Utveckla C#-klassbiblioteksfunktioner med hjälp av Azure Functions

Den här artikeln är en introduktion till att utveckla Azure Functions med hjälp av C# i .NET-klassbibliotek.

Viktigt

Den här artikeln stöder .NET-klassbiblioteksfunktioner som körs i processen med körningen. Functions stöder också .NET 5.x genom att köra dina C#-funktioner utanför processen och isolerade från körningen. Mer information finns i .NET-isolerade processfunktioner.

Som C#-utvecklare kan du också vara intresserad av någon av följande artiklar:

Komma igång Begrepp Interaktiv utbildning/exempel

Azure Functions har stöd för programmeringsspråken C# och C#. Om du behöver hjälp med att använda C#i Azure Portal , se C#-skript (.csx) utvecklarreferens.

Versioner som stöds

Versioner av Functions-körningen fungerar med specifika versioner av .NET. Mer information om Functions-versioner finns i Azure Functions översikt över körningsversioner. Versionsstöd beror på om dina funktioner körs i processen eller utanför processen (isolerade).

I följande tabell visas den högsta nivån av .NET Core eller .NET Framework som kan användas med en specifik version av Functions.

Körningsversion av Functions Pågår
(.NET-klassbibliotek)
Out-of-process (In-of-process)
(.NET Isolerad)
Functions 4.x1 .NET 6.0 (förhandsversion) .NET 6.0 (förhandsversion)
Functions 3.x .NET Core 3.1 .NET 5.0
Functions 2.x .NET Core 2.12 saknas
Functions 1.x .NET Framework 4.8 saknas

1 Azure Functions ger experimentellt stöd så att du kan prova dina funktioner som körs i förhandsversionen av .NET 6.0. Den här förhandsversionen stöds inte officiellt. Mer information finns på sidan Azure Functions v4 för tidig förhandsgranskning.
2 Mer information finns i Functions v2.x-överväganden.

För de senaste nyheterna Azure Functions versioner, inklusive borttagning av specifika äldre mindre versioner, kan du övervaka Azure App Service meddelanden.

Överväganden för Functions v2.x

Funktionsappar som har den senaste 2.x-versionen ( ) uppgraderas automatiskt för att köras ~2 på .NET Core 3.1. På grund av större ändringar mellan .NET Core-versioner kan inte alla appar som utvecklats och kompilerats mot .NET Core 2.2 uppgraderas på ett säkert sätt till .NET Core 3.1. Du kan välja bort den här uppgraderingen genom att fästa funktionsappen på ~2.0 . Functions identifierar även inkompatibla API:er och kan fästa appen på för att ~2.0 förhindra felaktig körning på .NET Core 3.1.

Anteckning

Om funktionsappen är fäst på och ~2.0 du ändrar det här versionsmålet till kan ~2 funktionsappen brytas. Om du distribuerar med arm-mallar kontrollerar du versionen i dina mallar. Om detta inträffar ändrar du tillbaka versionen till målet ~2.0 och åtgärdar kompatibilitetsproblem.

Funktionsappar som är ~2.0 mål fortsätter att köras på .NET Core 2.2. Den här versionen av .NET Core tar inte längre emot säkerhets- och andra underhållsuppdateringar. Mer information finns på den här meddelandesidan.

Du bör arbeta för att göra dina funktioner kompatibla med .NET Core 3.1 så snart som möjligt. När du har löst problemen ändrar du tillbaka versionen till ~2 eller uppgraderar till ~3 . Mer information om hur du riktar in dig på versioner av Functions-körningen finns i How to target Azure Functions runtime versions.

När du kör på Linux i en Premium- eller dedikerad (App Service)-plan fäster du din version genom att i stället rikta in dig på en viss avbildning genom att ange platskonfigurationsinställningen till Mer information om hur du anger finns i Manuella versionsuppdateringar i linuxFxVersion DOCKER|mcr.microsoft.com/azure-functions/dotnet:2.0.14786-appservice linuxFxVersion Linux.

Functions-klassbiblioteksprojekt

I Visual Studio skapar Azure Functions-projektmallen ett C#-klassbiblioteksprojekt som innehåller följande filer:

När du skapar projektet genereras en mappstruktur som ser ut som i följande exempel i utdatakatalogen:

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

Den här katalogen distribueras till funktionsappen i Azure. Bindningstilläggen som krävs i version 2.x av Functions-körningen läggs till i projektet som NuGet-paket.

Viktigt

Byggprocessen skapar en filfunction.jsfil för varje funktion. Den function.jsfilen är inte avsedd att redigeras direkt. Du kan inte ändra bindningskonfigurationen eller inaktivera funktionen genom att redigera den här filen. Information om hur du inaktiverar en funktion finns i Så här inaktiverar du funktioner.

Metoder som identifieras som funktioner

I ett klassbibliotek är en funktion en statisk metod med ett FunctionName - och -utlösarattribut, som du ser i följande exempel:

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

Attributet FunctionName markerar metoden som en startpunkt för funktionen. Namnet måste vara unikt inom ett projekt, börja med en bokstav och får bara innehålla bokstäver, siffror, och , med en längd på upp till _ - 127 tecken. Project skapar ofta en metod med namnet Run , men metodnamnet kan vara val annat giltigt C#-metodnamn.

Utlösarattributet anger utlösartypen och binder indata till en metodparameter. Exempelfunktionen utlöses av ett kömeddelande och kömeddelandet skickas till metoden i myQueueItem parametern .

Parametrar för metodsignatur

Metodsignaturen kan innehålla andra parametrar än de som används med utlösarattributet. Här är några av de andra parametrarna som du kan inkludera:

Ordningen på parametrarna i funktionssignaturen spelar ingen roll. Du kan till exempel placera utlösarparametrar före eller efter andra bindningar och du kan ange loggningsparametern före eller efter utlösaren eller bindningsparametrarna.

Utdatabindningar

En funktion kan ha noll eller en utdatabindning som definierats med hjälp av utdataparametrar.

I följande exempel ändras föregående genom att en utdataköbindning med namnet läggs myQueueItemCopy till. Funktionen skriver innehållet i meddelandet som utlöser funktionen till ett nytt meddelande i en annan kö.

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

Värden som tilldelas till utdatabindningar skrivs när funktionen avslutas. Du kan använda mer än en utdatabindning i en funktion genom att helt enkelt tilldela värden till flera utdataparametrar.

I bindningsreferensartiklarna ( Storage köer till exempel) förklaras vilka parametertyper du kan använda medbindningsattributför utlösare, indata eller utdata.

Exempel på bindningsuttryck

Följande kod hämtar namnet på kön som ska övervakas från en appinställning och hämtar skapandetiden för kömeddelandet i insertionTime parametern .

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

Automatiskt genererade function.jspå

Byggprocessen skapar en fil function.jsfil i en funktionsmapp i build-mappen. Som tidigare nämnts är den här filen inte avsedd att redigeras direkt. Du kan inte ändra bindningskonfigurationen eller inaktivera funktionen genom att redigera den här filen.

Syftet med den här filen är att ge information till skalningskontrollanten som ska användas för skalningsbeslut på förbrukningsplanen. Därför har filen bara utlösarinformation, inte indata-/utdatabindningar.

Den genereradefunction.jspå filen innehåller en egenskap som talar om för körningen att configurationSource använda .NET-attribut för bindningar, i stället för attfunction.jspå konfigurationen. Här är ett exempel:

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

Den function.jsvid filgenerering utförs av NuGet-paketet Microsoft NET Sdk . . . Functions.

Samma paket används för både version 1.x och 2.x av Functions-körningen. Målramverket är det som skiljer ett 1.x-projekt från ett 2.x-projekt. Här är de relevanta delarna i .csproj-filer som visar olika målramverk med samma Sdk paket:

<PropertyGroup>
  <TargetFramework>netcoreapp2.1</TargetFramework>
  <AzureFunctionsVersion>v2</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.8" />
</ItemGroup>

Bland Sdk paketberoendena finns utlösare och bindningar. Ett 1.x-projekt refererar till 1.x-utlösare och bindningar eftersom dessa utlösare och bindningar riktar sig mot .NET Framework, medan 2.x-utlösare och bindningar riktar in sig på .NET Core.

Paketet Sdk beror också påNewtonsoft.Js, och indirekt på WindowsAzure.Storage. Dessa beroenden ser till att projektet använder versionerna av de paket som fungerar med den Functions-körningsversion som projektet har som mål. Har till exempel Newtonsoft.Json version 11 för .NET Framework 4.6.1, men Functions-körningen som är inriktad på .NET Framework 4.6.1 är endast kompatibel med Newtonsoft.Json 9.0.1. Så funktionskoden i projektet måste också använda Newtonsoft.Json 9.0.1.

Källkoden för finns Microsoft.NET.Sdk.Functions på lagringsplatsen azure functions GitHub build - - - - sdk.

Lokal körningsversion

Visual Studio använder Azure Functions Core Tools för att köra Functions-projekt på den lokala datorn. Core Tools är ett kommandoradsgränssnitt för Functions-körningen.

Om du installerar Core Tools med hjälp av Windows Installer-paketet (MSI) eller med hjälp av npm påverkar det inte core tools-versionen som används av Visual Studio. För Functions runtime version 1.x lagrar Visual Studio Core Tools-versioner i %USERPROFILE%\AppData\Local\Azure.Functions.Cli och använder den senaste versionen som lagras där. För Functions 2.x ingår Core Tools i tillägget Azure Functions och Web Jobs Tools. För både 1.x och 2.x kan du se vilken version som används i konsolens utdata när du kör ett Functions-projekt:

[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

Du kan kompilera funktionsappen som ReadyToRun-binärfiler. ReadyToRun är en form av kompilering i förväg som kan förbättra startprestanda för att minska effekten av kallstart när den körs i en förbrukningsplan.

ReadyToRun är tillgängligt i .NET 3.0 och kräver version 3.0 Azure Functions runtime.

För att kompilera projektet som ReadyToRun uppdaterar du projektfilen genom att lägga till <PublishReadyToRun> <RuntimeIdentifier> elementen och . Följande är konfigurationen för publicering till en Windows 32-bitars funktionsapp.

<PropertyGroup>
  <TargetFramework>netcoreapp3.1</TargetFramework>
  <AzureFunctionsVersion>v3</AzureFunctionsVersion>
  <PublishReadyToRun>true</PublishReadyToRun>
  <RuntimeIdentifier>win-x86</RuntimeIdentifier>
</PropertyGroup>

Viktigt

ReadyToRun stöder för närvarande inte korskompilering. Du måste skapa din app på samma plattform som distributionsmålet. Var också uppmärksam på den "bitness" som har konfigurerats i funktionsappen. Om funktionsappen i Azure till exempel Windows 64-bitars måste du kompilera appen på Windows med som win-x64 körningsidentifierare.

Du kan också skapa din app med ReadyToRun från kommandoraden. Mer information finns i -p:PublishReadyToRun=true alternativet i dotnet publish .

Typer som stöds för bindningar

Varje bindning har sina egna typer som stöds. Ett blobutlösarattribut kan till exempel tillämpas på en strängparameter, en POCO-parameter, en parameter eller CloudBlockBlob någon av flera andra typer som stöds. I referensartikeln för bindningar för blobbindningar visas en lista över alla parametertyper som stöds. Mer information finns i Utlösare och bindningar och bindningsreferensdokumenten för varje bindningstyp.

Tips

Om du planerar att använda HTTP-eller webhook-bindningarna bör du planera för att undvika att port överbelastningen kan orsakas av felaktig instansiering av HttpClient . Mer information finns i hantera anslutningar i Azure Functions.

Bindning till metodreturvärde

Du kan använda ett metodreturvärde för en utdatabindning genom att tillämpa attributet på metodens returvärde. Exempel finns i Utlösare och bindningar.

Använd endast returvärdet om en lyckad funktionskörning alltid resulterar i ett returvärde som ska överföras till utdatabindningen. Annars använder du ICollector eller , som du ser i följande IAsyncCollector avsnitt.

Skriva flera utdatavärden

Om du vill skriva flera värden till en utdatabindning, eller om ett lyckat funktionsanrop inte leder till något att skicka till utdatabindningen, använder du ICollector typerna IAsyncCollector eller . Dessa typer är skrivskyddade samlingar som skrivs till utdatabindningen när metoden har slutförts.

Det här exemplet skriver flera kömeddelanden till samma kö med hjälp av 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}");
    }
}

Asynkrona

Om du vill göra en funktion asynkronanvänder du async nyckelordet och returnerar ett Task -objekt.

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

Du kan inte använda parametrar out i asynkrona funktioner. För utdatabindningar använder du funktionens returvärde eller ett insamlarobjekt i stället.

Annulleringstoken

En funktion kan acceptera parametern CancellationToken, som gör att operativsystemet kan meddela din kod när funktionen är på väg att avslutas. Du kan använda det här meddelandet för att se till att funktionen inte avslutas oväntat på ett sätt som lämnar data i ett inkonsekvent tillstånd.

I följande exempel visas hur du söker efter nära förestående funktionsavslut.

public static class CancellationTokenExample
{
    public static void Run(
        [QueueTrigger("inputqueue")] string inputText,
        TextWriter logger,
        CancellationToken token)
    {
        for (int i = 0; i < 100; i++)
        {
            if (token.IsCancellationRequested)
            {
                logger.WriteLine("Function was cancelled at iteration {0}", i);
                break;
            }
            Thread.Sleep(5000);
            logger.WriteLine("Normal processing for queue message={0}", inputText);
        }
    }
}

Loggning

I funktionskoden kan du skriva utdata till loggar som visas som spårningar i Application Insights. Det rekommenderade sättet att skriva till loggarna är att inkludera en parameter av typen ILogger, som vanligtvis heter log . Version 1.x av Functions-körningen använde , som även TraceWriter skriver till Application Insights, men inte stöder strukturerad loggning. Använd inte för Console.Write att skriva loggar eftersom dessa data inte samlas in av Application Insights.

ILogger

I funktionsdefinitionen inkluderar du en ILogger-parameter som stöder strukturerad loggning.

Med ett ILogger -objekt anropar du Log<level> tilläggsmetoder på ILogger för att skapa loggar. Följande kod skriver loggar Information med kategori Function.<YOUR_FUNCTION_NAME>.User. :

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

Mer information om hur Functions implementerar ILogger finns i Samla in telemetridata. Kategorier som föregås av Function förutsätter att du använder en ILogger -instans. Om du väljer att i stället använda ILogger<T> ett kan kategorinamnet i stället baseras på T .

Strukturerad loggning

Ordningen på platshållarna, inte deras namn, avgör vilka parametrar som används i loggmeddelandet. Anta att du har följande kod:

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

Om du behåller samma meddelandesträng och omvänt ordning på parametrarna får den resulterande meddelandetexten värdena på fel platser.

Platshållarna hanteras på det här sättet så att du kan göra strukturerad loggning. Program Insights lagrar parameternamn-värde-paren och meddelandesträngen. Resultatet är att meddelandeargumenten blir fält som du kan köra frågor mot.

Om ditt loggningsmetod-anrop ser ut som i föregående exempel kan du köra frågor mot fältet customDimensions.prop__rowKey . Prefixet prop__ läggs till för att säkerställa att det inte finns några kollisioner mellan fält som körningen lägger till och fält som funktionskoden lägger till.

Du kan också fråga efter den ursprungliga meddelandesträngen genom att referera till fältet customDimensions.prop__{OriginalFormat} .

Här är ett exempel på en JSON-representation av customDimensions data:

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

Logga anpassad telemetri

Det finns en Functions-specifik version av Application Insights SDK som du kan använda för att skicka anpassade telemetridata från dina funktioner till Application Insights: Microsoft.Azure.WebJobs.Logging.ApplicationInsights. Använd följande kommando från kommandotolken för att installera det här paketet:

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

I det här kommandot ersätter <VERSION> du med en version av det här paketet som stöder den installerade versionen av Microsoft.Azure.WebJobs.

I följande C#-exempel används det anpassade telemetri-API:et. Exemplet är för ett .NET-klassbibliotek, men Programkod Insights är samma för C#-skript.

Version 2.x och senare versioner av körningen använder nyare funktioner i Application Insights för att automatiskt korrelera telemetri med den aktuella åtgärden. Du behöver inte ange åtgärden , eller fälten Id ParentId Name manuellt.

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

I det här exemplet aggregeras anpassade måttdata av värden innan de skickas till tabellen customMetrics. Mer information finns i GetMetric-dokumentationen i Application Insights.

När du kör lokalt måste du lägga till inställningen, med APPINSIGHTS_INSTRUMENTATIONKEY nyckeln Application Insights, tilllocal.settings.js filen.

Anropa inte eller TrackRequest eftersom StartOperation<RequestTelemetry> du ser duplicerade begäranden för ett funktionsanrop. Functions-körningen spårar automatiskt begäranden.

Ange inte telemetryClient.Context.Operation.Id . Den här globala inställningen orsakar felaktig korrelation när många funktioner körs samtidigt. Skapa i stället en ny telemetriinstans ( DependencyTelemetry , ) och ändra dess EventTelemetry Context egenskap. Skicka sedan telemetriinstansen till motsvarande Track metod på ( , , TelemetryClient TrackDependency() TrackEvent() TrackMetric() ). Den här metoden säkerställer att telemetrin har rätt korrelationsinformation för det aktuella funktionsanropet.

Miljövariabler

Om du vill hämta en miljövariabel eller ett appinställningsvärde System.Environment.GetEnvironmentVariable använder du , som du ser i följande kodexempel:

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

Appinställningar kan läsas från miljövariabler både när du utvecklar lokalt och när du kör i Azure. När du utvecklar lokalt kommer appinställningar från Values samlingen ilocal.settings.js filen. I båda miljöerna, lokalt och Azure, GetEnvironmentVariable("<app setting name>") hämtar värdet för den namngivna appinställningen. När du till exempel kör lokalt returneras "Mitt platsnamn" om ditt lokalalocal.settings.js innehåller { "Values": { "WEBSITE_SITE_NAME": "My Site Name" } } .

Egenskapen System.Configuration.ConfigurationManager.AppSettings är ett alternativt API för att hämta appinställningsvärden, men vi rekommenderar att du använder GetEnvironmentVariable det som visas här.

Bindning vid körning

I C# och andra .NET-språk kan du använda ett imperativt bindningsmönster, till skillnad från deklarativa bindningar i attribut. Imperativ bindning är användbart när bindningsparametrar behöver beräknas vid körning i stället för designtiden. Med det här mönstret kan du binda till indata- och utdatabindningar som stöds i farten i funktionskoden.

Definiera en imperativ bindning på följande sätt:

  • Inkludera inte ett attribut i funktionssignaturen för dina önskade imperativbindningar.

  • Skicka in en indataparameter Binder binder eller IBinder binder .

  • Använd följande C#-mönster för att utföra databindningen.

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

    BindingTypeAttribute är det .NET-attribut som definierar bindningen och T är en indata- eller utdatatyp som stöds av den bindningstypen. T kan inte vara out en parametertyp (till exempel out JObject ). Till exempel stöder Mobile Apps tabellutdatabindning sex utdatatyper ,men du kan bara använda ICollector <T> eller IAsyncCollector <T> med imperativ bindning.

Exempel på ett enskilt attribut

Följande exempelkod skapar en Storage blob-utdatabindning med blobsökvägen som definieras vid körning och skriver sedan en sträng till bloben.

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 definierar Storage blobindata- eller utdatabindning och TextWriter är en utdatabindningstyp som stöds.

Exempel på flera attribut

I föregående exempel hämtar appinställningen för funktionsappens huvudkontoanslutningssträng Storage (vilket är AzureWebJobsStorage ). Du kan ange en anpassad appinställning som ska användas för Storage-kontot genom att lägga till StorageAccountAttribute och skicka attributmatrisen till BindAsync<T>() . Använd en Binder parameter, inte IBinder . Ett exempel:

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!!");
        }
    }
}

Utlösare och bindningar

I den här tabellen visas de bindningar som stöds i huvud versionerna av Azure Functions Runtime:

Typ 1.x 2. x och högre1 Utlösare Indata Resultat
Blob Storage
Azure Cosmos DB
Dapr3
Event Grid
Event Hubs
HTTP &-Webhooks
IoT Hub
Kafka2
Mobile Apps
Notification Hubs
Queue Storage
Rabbitmq2
SendGrid
Service Bus
SignalR
Table Storage
Timer
Twilio

1 från och med version 2. x-körningen måste alla bindningar utom http och timer registreras. Se Registrera bindnings tillägg.

2 utlösare stöds inte i förbruknings planen. Kräver runtime-drivna utlösare.

3 stöds endast i Kubernetes, IoT Edge och andra egna lägen.

Nästa steg