C#-osztálytárfüggvények fejlesztése az Azure Functions használatával

Ez a cikk az Azure Functions .NET-osztálykódtárak C# használatával történő fejlesztésének bemutatása. Ezek az osztálykódtárak a Függvények futtatókörnyezettel való folyamat közbeni futtatására szolgálnak. A .NET-függvények _isolated is futtathatnak a Functions-futtatókörnyezetből, ami számos előnnyel jár. További információkért tekintse meg az izolált feldolgozói modellt. A két modell átfogó összehasonlítását a folyamatban lévő modell és az izolált feldolgozói modell közötti különbségek című témakörben tekinti meg.

Fontos

Ez a cikk támogatja a futtatókörnyezettel folyamatban futó .NET-osztálytárfüggvényeket. A C#-függvények folyamaton kívül is elfogyhatnak, és elkülöníthetők a Functions-futtatókörnyezettől. Az izolált feldolgozói folyamatmodell az egyetlen mód a .NET nem LTS-verzióinak futtatására, és .NET-keretrendszer alkalmazások futtatására a Functions-futtatókörnyezet aktuális verzióiban. További információ: .NET izolált feldolgozói folyamatfüggvények. Az izolált feldolgozói folyamat és a folyamaton belüli .NET-függvények átfogó összehasonlítását lásd : Különbségek a folyamatban lévő és a feldolgozói folyamat elkülönítése között .NET Azure Functions.

C#-fejlesztőként az alábbi cikkek valamelyike is érdekelheti:

Első lépések Fogalmak Irányított tanulás/minták

Az Azure Functions támogatja a C# és a C# szkriptek programozási nyelvét. Ha útmutatást szeretne kapni a C# Azure Portalon való használatához, tekintse meg a C# szkripttel (.csx) kapcsolatos fejlesztői referenciaanyagot.

Támogatott verziók

A Functions-futtatókörnyezet verziói támogatják a .NET egyes verzióit. A Functions-verziókkal kapcsolatos további információkért tekintse meg az Azure Functions futtatókörnyezeti verzióinak áttekintését. A verziótámogatás attól is függ, hogy a függvények folyamatban vagy izolált feldolgozófolyamatban futnak-e.

Feljegyzés

A függvényalkalmazás által használt Functions-futtatókörnyezeti verzió módosításának megismeréséhez tekintse meg és frissítse az aktuális futtatókörnyezeti verziót.

Az alábbi táblázat a .NET vagy .NET-keretrendszer legmagasabb szintjét mutatja be, amely a Functions egy adott verziójával használható.

Functions futtatókörnyezet verziója Izolált feldolgozói modell Folyamatközi modell5
Functions 4.x .NET 8.0
.NET 7.01
.NET 6.02
.NET-keretrendszer 4,83
.NET 6.02
Functions 1.x4 n.a. .NET-keretrendszer 4.8

Az 1 .NET 7 2024. május 14-én véget ér a hivatalos támogatásnak .
A 2 .NET 6 2024. november 12-én véget ér a hivatalos támogatásnak .
3 A buildelési folyamathoz a .NET SDK is szükséges. 4 Az Azure Functions-futtatókörnyezet 1.x verziójának támogatása 2026. szeptember 14-én megszűnik. További információkért tekintse meg ezt a támogatási közleményt. A folyamatos teljes támogatás érdekében át kell telepítenie az alkalmazásokat a 4.x verzióra.
5 A folyamaton belüli modell támogatása 2026. november 10-én megszűnik. További információkért tekintse meg ezt a támogatási közleményt. A folyamatos teljes támogatás érdekében az alkalmazásokat át kell telepítenie az izolált feldolgozói modellbe.

Az Azure Functions-kiadásokkal kapcsolatos legfrissebb hírekért, beleértve a régebbi alverziók eltávolítását is, figyelje Azure-alkalmazás szolgáltatásjelentéseket.

Függvényosztálytár projektje

A Visual Studióban az Azure Functions-projektsablon létrehoz egy C# osztálytárprojektet, amely a következő fájlokat tartalmazza:

  • host.json – tárolja a konfigurációs beállításokat, amelyek hatással vannak a projekt összes függvényére helyi vagy Azure-beli futtatáskor.
  • local.settings.json – tárolja a helyi futtatáskor használt alkalmazásbeállításokat és kapcsolati sztring. Ez a fájl titkos kódokat tartalmaz, és nem teszi közzé az Azure-beli függvényalkalmazásban. Ehelyett adjon hozzá alkalmazásbeállításokat a függvényalkalmazáshoz.

A projekt létrehozásakor a következő példához hasonló mappastruktúra jön létre a build kimeneti könyvtárában:

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

Ez a könyvtár lesz üzembe helyezve a függvényalkalmazásban az Azure-ban. A Functions-futtatókörnyezet 2.x verziójában szükséges kötésbővítmények NuGet-csomagokként lesznek hozzáadva a projekthez.

Fontos

A buildelési folyamat minden függvényhez létrehoz egy function.json fájlt. Ez a function.json fájl nem közvetlenül szerkeszthető. A fájl szerkesztésével nem módosíthatja a kötéskonfigurációt, és nem tilthatja le a függvényt. A függvények letiltásának módjáról a Függvények letiltása című témakörben olvashat.

Függvényként felismert metódusok

Az osztálytárakban a függvények metódusok és FunctionName triggerattribútumok, ahogyan az a következő példában látható:

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

Az FunctionName attribútum függvénybejegyzési pontként jelöli meg a metódust. A névnek egyedinek kell lennie egy projekten belül, betűvel kell kezdődnie, és csak betűket, _számokat és -legfeljebb 127 karakter hosszúságú karaktereket kell tartalmaznia. A projektsablonok gyakran létrehoznak egy metódust, Runde a metódus neve bármilyen érvényes C# metódusnév lehet. A fenti példa egy statikus metódust mutat be, de a függvények nem szükségesek statikusak.

Az eseményindító attribútum megadja az eseményindító típusát, és a bemeneti adatokat egy metódusparaméterhez köti. A példafüggvényt egy üzenetsor-üzenet aktiválja, és a rendszer átadja az üzenetsor-üzenetet a paraméter metódusának myQueueItem .

Metódus aláírási paraméterei

A metódus-aláírás az eseményindító attribútummal használttól eltérő paramétereket tartalmazhat. Az alábbiakban néhány további paramétert is megadhat:

A függvény-aláírás paramétereinek sorrendje nem számít. Például triggerparamétereket helyezhet el más kötések előtt vagy után, és a naplózó paramétert az eseményindító vagy kötés paraméterei elé vagy után is elhelyezheti.

Kimeneti kötések

A függvények kimeneti paraméterek használatával nulla vagy több kimeneti kötéssel is rendelkezhetnek.

Az alábbi példa az előzőt módosítja egy kimeneti üzenetsor-kötés hozzáadásával.myQueueItemCopy A függvény annak az üzenetnek a tartalmát írja, amely a függvényt egy másik üzenetsor új üzenetére aktiválja.

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

A kimeneti kötésekhez rendelt értékek a függvény kilépésekor lesznek megírva. Egy függvényben több kimeneti kötést is használhat, ha egyszerűen több kimeneti paraméterhez rendel értékeket.

A kötési referenciacikkek (például tárolási üzenetsorok) ismertetik, hogy mely paramétertípusokat használhatja eseményindító, bemeneti vagy kimeneti kötési attribútumokkal.

Példa kötési kifejezésekre

Az alábbi kód lekéri a monitorozni kívánt üzenetsor nevét egy alkalmazásbeállításból, és megkapja az üzenetsor üzenetlétrehozásának idejét a insertionTime paraméterben.

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

Automatikusan létrehozott function.json

A buildelési folyamat létrehoz egy function.json fájlt a buildmappa egyik függvénymappájában. Ahogy korábban említettük, a fájl nem közvetlenül szerkeszthető. A fájl szerkesztésével nem módosíthatja a kötéskonfigurációt, és nem tilthatja le a függvényt.

Ennek a fájlnak az a célja, hogy információt nyújtson a méretezési vezérlőnek a használati terv skálázási döntéseihez. Ezért a fájl csak triggerinformációkkal rendelkezik, bemeneti/kimeneti kötésekkel nem.

A létrehozott function.json fájl tartalmaz egy tulajdonságotconfigurationSource, amely arra utasítja a futtatókörnyezetet, hogy function.json konfiguráció helyett .NET-attribútumokat használjon kötésekhez. Példa:

{
  "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 function.json fájlgenerálást a Microsoft.NET.Sdk.Functions NuGet-csomag végzi.

Az alábbi példa azokat a .csproj fájlrészeket mutatja be, amelyek különböző célkeretekkel rendelkeznek ugyanahhoz Sdk a csomaghoz:

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

A csomagfüggőségek közé tartoznak az Sdk eseményindítók és a kötések. Az 1.x projekt 1.x eseményindítókra és kötésekre hivatkozik, mivel ezek az eseményindítók és kötések a .NET-keretrendszer, míg a 4.x triggerek és kötések a .NET Core-t célják.

A Sdk csomag a Newtonsoft.Jsontól és közvetetten a WindowsAzure.Storage-tól is függ. Ezek a függőségek biztosítják, hogy a projekt azoknak a csomagoknak a verzióit használja, amelyek a projekt által célként megadott Functions-futtatókörnyezeti verzióval működnek. A .NET-keretrendszer 4.6.1-es verziójához például Newtonsoft.Json a 11-es verzió tartozik, de a .NET-keretrendszer 4.6.1-es verziójú Functions-futtatókörnyezet csak a 9.0.1-es verzióval Newtonsoft.Json kompatibilis. A projektben lévő függvénykódnak tehát a 9.0.1-et is használnia Newtonsoft.Json kell.

A forráskód Microsoft.NET.Sdk.Functions az azure-functions-vs-build-sdk GitHub-adattárban érhető el.

Helyi futtatókörnyezet verziója

A Visual Studio az Azure Functions Core Tools használatával futtat függvényprojekteket a helyi számítógépen. A Core Tools egy parancssori felület a Functions-futtatókörnyezethez.

Ha a Core Toolst a Windows installer (MSI) csomaggal vagy az npm használatával telepíti, az nem érinti a Visual Studio által használt Core Tools-verziót. A Functions 1.x-es verziójához a Visual Studio a Core Tools-verziókat %U Standard kiadás RPROFILE%\AppData\Local\Azure.Functions.Cli formátumban tárolja, és az ott tárolt legújabb verziót használja. A Functions 4.x esetében a Core Tools az Azure Functions és a Web Jobs Tools bővítmény részét képezi. A Functions 1.x esetében láthatja, hogy milyen verziót használ a konzol kimenete a Functions-projekt futtatásakor:

[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

A függvényalkalmazást ReadyToRun bináris fájlokként fordíthatja le. A ReadyToRun az idő előtti összeállítás egy formája, amely javíthatja az indítási teljesítményt, hogy csökkentse a hidegindítás hatását a használatalapú csomagban való futtatáskor.

A ReadyToRun a .NET 6-os és újabb verzióiban érhető el, és az Azure Functions-futtatókörnyezet 4.0-s verzióját igényli.

A projekt ReadyToRunként való fordításához frissítse a projektfájlt az elemek és <RuntimeIdentifier> az <PublishReadyToRun> elemek hozzáadásával. Az alábbiakban a Windows 32 bites függvényalkalmazásokban való közzététel konfigurációját követve tesszük közzé.

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

Fontos

A .NET 6-tól kezdve az összetett ReadyToRun-fordítás támogatása meg lett adva. Tekintse meg a ReadyToRun platformfüggetlen és architektúrakorlátozásait.

A Parancssorból a ReadyToRun használatával is létrehozhatja az alkalmazást. További információkért tekintse meg a következő lehetőséget: .</a0-p:PublishReadyToRun=true>

A kötések támogatott típusai

Minden kötés saját támogatott típusokkal rendelkezik; A blob trigger attribútuma például alkalmazható sztringparaméterre, POCO-paraméterre, paraméterre CloudBlockBlob vagy számos más támogatott típusra. A blobkötések kötési referenciacikke felsorolja az összes támogatott paramétertípust. További információkért tekintse meg az eseményindítókat és kötéseket , valamint az egyes kötéstípusok kötési referencia-dokumentumait.

Tipp.

Ha HTTP- vagy WebHook-kötéseket szeretne használni, tervezze meg, hogy elkerülje a portkimerülést, amelyet a nem megfelelő példányosítás HttpClientokozhat. További információ: Kapcsolatok kezelése az Azure Functionsben.

Kötés a metódus visszatérési értékéhez

Egy kimeneti kötés metódus-visszatérési értékét úgy használhatja, hogy az attribútumot a metódus visszatérési értékére alkalmazza. Példák : Triggerek és kötések.

A visszatérési értéket csak akkor használja, ha egy sikeres függvény végrehajtása mindig visszatérési értéket eredményez a kimeneti kötésnek való továbbításhoz. Ellenkező esetben használja ICollector vagy IAsyncCollectorhasználja az alábbi szakaszban látható módon.

Több kimeneti érték írása

Ha több értéket szeretne írni egy kimeneti kötésbe, vagy ha egy sikeres függvényhívás nem eredményez semmit a kimeneti kötésnek való továbbításhoz, használja a típusokat vagy IAsyncCollector a ICollector típusokat. Ezek a típusok írásvédett gyűjtemények, amelyeket a metódus befejezésekor a kimeneti kötésbe írnak.

Ez a példa több üzenetsor-üzenetet ír ugyanabba az üzenetsorba a következő használatával 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}");
    }
}

Aszinkron

Ha aszinkron függvényt szeretne létrehozni, használja a async kulcsszót, és adjon vissza egy objektumotTask.

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

Az aszinkron függvényekben nem használhatók out paraméterek. Kimeneti kötésekhez használja inkább a függvény visszatérési értékét vagy gyűjtőobjektumot.

Lemondási jogkivonatok

A függvények elfogadhatnak egy CancellationToken paramétert, amely lehetővé teszi, hogy az operációs rendszer értesítse a kódot, amikor a függvény leáll. Ezzel az értesítéssel meggyőződhet arról, hogy a függvény nem fejeződik be váratlanul oly módon, hogy az adatok inkonzisztens állapotban maradnak.

Vegye figyelembe az esetet, ha olyan függvénye van, amely kötegekben dolgozza fel az üzeneteket. Az alábbi Azure Service Bus által aktivált függvény ServiceBusReceivedMessage objektumok tömbjeit dolgozza fel, amelyek egy adott függvényhívás által feldolgozandó bejövő üzenetek kötegét jelölik:

using Azure.Messaging.ServiceBus;
using System.Threading;

namespace ServiceBusCancellationToken
{
    public static class servicebus
    {
        [FunctionName("servicebus")]
        public static void Run([ServiceBusTrigger("csharpguitar", Connection = "SB_CONN")]
               ServiceBusReceivedMessage[] 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}");
            }
        }
    }
}

Naplózás

A függvénykódban olyan naplókba írhat kimenetet, amelyek nyomkövetésként jelennek meg az Alkalmazás Elemzések. A naplókba való írás ajánlott módja az, ha egy jellemzően elnevezett logILogger típusú paramétert tartalmaz. A használt TraceWriterFunctions-futtatókörnyezet 1.x-es verziója, amely az Application Elemzések is ír, de nem támogatja a strukturált naplózást. Ne használja Console.Write a naplók írását, mivel ezeket az adatokat nem rögzíti az alkalmazás Elemzések.

ILogger

A függvénydefinícióban adjon meg egy ILogger paramétert, amely támogatja a strukturált naplózást.

ILogger Egy objektummal az ILogger bővítménymetódusait hívhatja Log<level>meg naplók létrehozásához. A következő kód naplókat Information ír a kategóriával Function.<YOUR_FUNCTION_NAME>.User.:

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

Ha többet szeretne megtudni a Functions implementálásárólILogger, olvassa el a telemetriai adatok gyűjtését ismertető témakört. Az előtaggal Function ellátott kategóriák feltételezik, hogy egy példányt ILogger használ. Ha inkább egy kategóriát ILogger<T>használ, a kategória neve a következő lehet T: .

Strukturált naplózás

A helyőrzők sorrendje nem a nevük, hanem a naplóüzenetben használt paramétereket határozza meg. Tegyük fel, hogy a következő kóddal rendelkezik:

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

Ha megtartja ugyanazt az üzenetsztringet, és megfordítja a paraméterek sorrendjét, az eredményül kapott üzenetszöveg nem a megfelelő helyeken lévő értékeket tartalmazza.

A helyőrzőket így kezeli a rendszer, így strukturált naplózást végezhet. Az alkalmazás Elemzések tárolja a paraméter név-érték párjait és az üzenetsztringet. Az eredmény az, hogy az üzenet argumentumai olyan mezőkké válnak, amelyeken lekérdezhető.

Ha a naplózó metódushívása az előző példához hasonlóan néz ki, lekérdezheti a mezőt customDimensions.prop__rowKey. A prop__ program hozzáadja az előtagot, hogy ne legyen ütközés a futtatókörnyezet által hozzáadott mezők és a függvénykód által hozzáadott mezők között.

Az eredeti üzenetsztringet a mezőre customDimensions.prop__{OriginalFormat}való hivatkozással is lekérdezheti.

Az adatok JSON-mintaképe customDimensions :

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

Egyéni telemetriai adatok naplózása

Az alkalmazás Elemzések SDK egy függvényspecifikus verziója, amellyel egyéni telemetriai adatokat küldhet a függvényekből az Alkalmazás Elemzések: Microsoft.Azure.WebJobs.Logging.Application Elemzések. A csomag telepítéséhez használja a következő parancsot a parancssorból:

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

Ebben a parancsban cserélje le <VERSION> a csomag egy olyan verzióját, amely támogatja a Microsoft.Azure.WebJobs telepített verzióját.

Az alábbi C#-példák az egyéni telemetriai API-t használják. A példa egy .NET-osztálykódtárra vonatkozik, de az Alkalmazás Elemzések kód ugyanaz a C# szkript esetében.

A futtatókörnyezet 2.x és újabb verziói az Application Elemzések újabb funkcióival automatikusan korrelálják a telemetriát az aktuális művelettel. Nincs szükség a művelet IdParentIdName vagy mezők manuális beállítására.

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

Ebben a példában az egyéni metrikák adatait a gazdagép összesíti, mielőtt elküldené őket a customMetrics táblába. További információkért tekintse meg az Application Elemzések GetMetric dokumentációját.

Helyi futtatáskor hozzá kell adnia a beállítást az APPINSIGHTS_INSTRUMENTATIONKEY Alkalmazás Elemzések kulccsal a local.settings.json fájlhoz.

Ne hívjon, TrackRequest vagy StartOperation<RequestTelemetry> mert ismétlődő kérések jelennek meg egy függvényhíváshoz. A Functions-futtatókörnyezet automatikusan nyomon követi a kéréseket.

Ne állítsa be a parancsot telemetryClient.Context.Operation.Id. Ez a globális beállítás helytelen korrelációt okoz, ha számos függvény fut egyszerre. Ehelyett hozzon létre egy új telemetriai példányt (DependencyTelemetry, EventTelemetry) és módosítsa annak tulajdonságát Context . Ezután adja át a telemetriai példányt a megfelelő Track metódusnak TelemetryClient (TrackDependency(), , TrackEvent()). TrackMetric() Ez a módszer biztosítja, hogy a telemetria a megfelelő korrelációs adatokkal rendelkezik az aktuális függvényhíváshoz.

Függvények tesztelése

Az alábbi cikkek bemutatják, hogyan futtathat helyben egy folyamaton belüli C# osztálytárfüggvényt tesztelési célokra:

Környezeti változók

Környezeti változó vagy alkalmazásbeállítási érték lekéréséhez használja System.Environment.GetEnvironmentVariablea következő kód példában látható módon:

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

Az alkalmazásbeállítások beolvashatók a környezeti változókból helyi fejlesztéskor és az Azure-ban való futtatáskor is. Helyi fejlesztéskor az alkalmazásbeállítások a Values local.settings.json fájl gyűjteményéből származnak. Mindkét környezetben a helyi és az Azure GetEnvironmentVariable("<app setting name>") lekéri a névvel ellátott alkalmazásbeállítás értékét. Ha például helyileg fut, a "Saját webhely neve" lesz visszaadva, ha a local.settings.json fájl tartalmaz { "Values": { "WEBSITE_SITE_NAME": "My Site Name" } }.

A System.Configuration.ConfigurationManager.App Gépház tulajdonság egy alternatív API az alkalmazásbeállítási értékek lekéréséhez, de azt javasoljuk, hogy az itt látható módon használjaGetEnvironmentVariable.

Kötés futásidőben

C# és más .NET-nyelvekben imperatív kötési mintát használhat, szemben az attribútumok deklaratív kötésével. Az imperatív kötés akkor hasznos, ha a kötési paramétereket futásidőben kell kiszámítani a tervezési idő helyett. Ezzel a mintával a függvénykódban menet közben csatlakozhat a támogatott bemeneti és kimeneti kötésekhez.

Adjon meg egy imperatív kötést az alábbiak szerint:

  • A kívánt imperatív kötésekhez ne adjon meg attribútumot a függvény-aláírásban.

  • Adjon meg egy bemeneti paramétert Binder binder vagy IBinder binder.

  • Az adatkötés végrehajtásához használja az alábbi C#-mintát.

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

    BindingTypeAttribute a kötést meghatározó .NET-attribútum, amely T az adott kötéstípus által támogatott bemeneti vagy kimeneti típus. T nem lehet out paramétertípus (például out JObject). A Mobile Apps tábla kimeneti kötése például hat kimeneti típust támogat, de az ICollector<T> vagy az IAsyncCollector<T> csak imperatív kötéssel használható.

Példa egy attribútumra

Az alábbi példakód létrehoz egy Storage-blob kimeneti kötést a futtatáskor definiált blob elérési útjával, majd sztringet ír a blobhoz.

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

A BlobAttribute a Storage-blob bemeneti vagy kimeneti kötését határozza meg, a TextWriter pedig egy támogatott kimeneti kötéstípus.

Több attribútum – példa

Az előző példa lekéri a függvényalkalmazás fő Storage-fiókjának alkalmazásbeállítását kapcsolati sztring (azaz AzureWebJobsStorage). A Storage-fiókhoz használandó egyéni alkalmazásbeállítást úgy adhatja meg, hogy hozzáadja a StorageAccountAttribute értéket, és átadja az attribútumtömböt a tárfióknak BindAsync<T>(). Használjon paramétert Binder , ne IBinder. Példa:

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

Eseményindítók és kötések

Ez a táblázat az Azure Functions-futtatókörnyezet fő verzióiban támogatott kötéseket mutatja be:

Típus 1.x1 2.x és magasabb2 Eseményindító Bevitel Hozam
Blob Storage
Azure Cosmos DB
Azure Data Explorer
Azure SQL
Dapr4
Event Grid
Event Hubs
HTTP > webhookok
IoT hub
Kafka3
Mobile Apps
Értesítési központ
Queue Storage
Redis
RabbitMQ3
SendGrid
Szolgáltatásbusz
SignalR
Table Storage
Időzítő
Twilio

1Az Azure Functions-futtatókörnyezet 1.x verziójának támogatása 2026. szeptember 14-én megszűnik. Javasoljuk, hogy a teljes támogatás érdekében migrálja az alkalmazásokat a 4.x-es verzióra.

2 A 2.x-es futtatókörnyezettől kezdve a HTTP és az Időzítő kivételével minden kötést regisztrálni kell. Lásd: Kötésbővítmények regisztrálása.

3 Az eseményindítók nem támogatottak a Használati tervben. Futásidejű eseményindítókat igényel.

4 Csak a Kubernetesben, az IoT Edge-ben és más saját üzemeltetésű módokban támogatott.

Következő lépések