Vývoj funkcí knihovny tříd jazyka C# pomocí Azure Functions

Tento článek je úvodem k vývoji azure Functions pomocí jazyka C# v knihovnách tříd .NET. Tyto knihovny tříd se používají ke spuštění v procesu pomocí modulu runtime Služby Functions. Funkce .NET můžou alternativně spouštět _isolated z modulu runtime Functions, který nabízí několik výhod. Další informace najdete v izolovaném modelu pracovního procesu. Komplexní porovnání těchto dvou modelů najdete v tématu Rozdíly mezi modelem v procesu a izolovaným modelem pracovního procesu.

Jako vývojář jazyka C# vás může také zajímat jeden z následujících článků:

Azure Functions podporuje programovací jazyky C# a C#. Pokud hledáte pokyny k používání jazyka C# na webu Azure Portal, přečtěte si referenční informace pro vývojáře v jazyce C# (.csx).

Podporované verze

Verze modulu runtime Služby Functions podporují konkrétní verze rozhraní .NET. Další informace o verzích functions najdete v přehledu verzí modulu runtime Azure Functions. Podpora verzí také závisí na tom, jestli vaše funkce běží v procesu nebo izolovaný pracovní proces.

Následující tabulka ukazuje nejvyšší úroveň rozhraní .NET nebo .NET Framework, kterou je možné použít s konkrétní verzí funkcí.

¹ .NET 7 bylo dříve podporováno v izolovaném modelu pracovních procesů, ale dosáhlo konce oficiální podpory 14. května 2024.

² .NET 6 dosáhne konce oficiální podpory 12. listopadu 2024.

³ Proces sestavení také vyžaduje sadu .NET SDK.

⁴ Podpora modulu runtime Azure Functions končí 1.x 14. září 2026. Další informace najdete v tomto oznámení podpory. Pokud chcete pokračovat v plné podpoře, měli byste migrovat aplikace na verzi 4.x.

⁵ Podpora modelu v procesu končí 10. listopadu 2026. Další informace najdete v tomto oznámení podpory. Pokud chcete pokračovat v plné podpoře, měli byste své aplikace migrovat do izolovaného pracovního modelu.

Nejnovější zprávy o vydaných verzích Azure Functions, včetně odebrání konkrétních starších podverzí, monitorujte oznámení služby Aplikace Azure.

Aktualizace na cíl .NET 8

Aplikace využívající model v procesu můžou cílit na .NET 8 podle kroků popsaných v této části. Pokud se však rozhodnete tuto možnost uplatnit, měli byste pokračovat v plánování migrace na izolovaný model pracovního procesu před ukončením podpory modelu v procesu 10. listopadu 2026.

Mnoho aplikací může změnit konfiguraci aplikace funkcí v Azure bez aktualizací kódu nebo opětovného nasazení. Ke spuštění .NET 8 s modelem v procesu se vyžadují tři konfigurace:

• Nastavení FUNCTIONS_WORKER_RUNTIME aplikace musí být nastaveno s hodnotou dotnet.
• Nastavení FUNCTIONS_EXTENSION_VERSION aplikace musí být nastaveno s hodnotou ~4.
• Nastavení aplikace FUNCTIONS_INPROC_NET8_ENABLED musí být nastaveno s hodnotou 1.
• Musíte aktualizovat konfiguraci zásobníku tak, aby odkazovat na .NET 8.

Podpora rozhraní .NET 8 stále používá verzi 4.x modulu runtime Služby Functions a nevyžaduje se žádná změna nakonfigurované verze modulu runtime.

Pokud chcete aktualizovat místní projekt, nejprve se ujistěte, že používáte nejnovější verze místních nástrojů. Pak se ujistěte, že projekt odkazuje na verzi 4.4.0 nebo novější sady Microsoft.NET.Sdk.Functions. Pak můžete změnit TargetFramework hodnotu net8.0. Musíte také aktualizovat local.settings.json tak, aby zahrnoval FUNCTIONS_WORKER_RUNTIME jak hodnotu dotnet, FUNCTIONS_INPROC_NET8_ENABLED tak i hodnotu 1.

Následuje příklad minimálního project souboru s těmito změnami:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.4.0" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Následuje příklad minimálního local.settings.json souboru s těmito změnami:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_INPROC_NET8_ENABLED": "1",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet"
    }
}

Pokud vaše aplikace používá Microsoft.Azure.DurableTask.Netherite.AzureFunctions, ujistěte se, že cílí na verzi 1.5.3 nebo novější. Kvůli změně chování v .NET 8 způsobí aplikace se staršími verzemi balíčku nejednoznačný výjimku konstruktoru.

Možná budete muset v aplikaci provést další změny na základě podpory verzí jejích dalších závislostí.

Modul runtime Functions verze 4.x poskytuje ekvivalentní funkce pro .NET 6 a .NET 8. Model v procesu neobsahuje další funkce ani aktualizace, které se integrují s novými funkcemi .NET 8. Modul runtime například nepodporuje služby s klíči. Pokud chcete plně využít nejnovější funkce a vylepšení .NET 8, musíte provést migraci do izolovaného pracovního modelu.

Projekt knihovny tříd Functions

V sadě Visual Studio vytvoří šablona projektu Azure Functions projekt knihovny tříd jazyka C#, který obsahuje následující soubory:

• host.json – ukládá nastavení konfigurace, která ovlivňují všechny funkce v projektu při místním spuštění nebo v Azure.
• local.settings.json – ukládá nastavení aplikací a připojovací řetězec, které se používají při místním spuštění. Tento soubor obsahuje tajné kódy a není publikovaný do vaší aplikace funkcí v Azure. Místo toho přidejte do aplikace funkcí nastavení aplikace.

Při sestavování projektu se ve výstupním adresáři sestavení vygeneruje struktura složek, která vypadá jako v následujícím příkladu:

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

Tento adresář je to, co se nasadí do vaší aplikace funkcí v Azure. Rozšíření vazeb požadovaná ve verzi 2.x modulu runtime Functions se do projektu přidají jako balíčky NuGet.

Metody rozpoznané jako funkce

V knihovně tříd je funkce metodou s atributem triggeru FunctionName , jak je znázorněno v následujícím příkladu:

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

Atribut FunctionName označuje metodu jako vstupní bod funkce. Název musí být v rámci projektu jedinečný, musí začínat písmenem a obsahovat pouze písmena, _číslice a -až 127 znaků. Šablony projektů často vytvářejí metodu s názvem Run, ale název metody může být libovolný platný název metody jazyka C#. Výše uvedený příklad ukazuje použitou statickou metodu, ale funkce nemusí být statické.

Atribut triggeru určuje typ triggeru a vytvoří vazbu vstupních dat na parametr metody. Ukázková funkce se aktivuje zprávou fronty a zpráva fronty se předá metodě v parametru myQueueItem .

Parametry podpisu metody

Podpis metody může obsahovat jiné parametry než parametry použité s atributem triggeru. Tady jsou některé další parametry, které můžete zahrnout:

• Vstupní a výstupní vazby označené jako takové jejich dekorací pomocí atributů.
• Parametr ILogger nebo TraceWriter (verze 1.x-only) pro protokolování
• Parametr CancellationToken pro řádné vypnutí.
• Parametry vazby výrazů pro získání metadat triggeru

Pořadí parametrů v podpisu funkce nezáleží. Parametry triggeru můžete například umístit před nebo za jiné vazby a parametr protokolovacího nástroje můžete umístit před nebo za parametry triggeru nebo vazby.

Výstupní vazby

Funkce může mít nulové nebo více výstupních vazeb definovaných pomocí výstupních parametrů.

Následující příklad upraví předchozí tím, že přidá výstupní vazbu fronty s názvem myQueueItemCopy. Funkce zapíše obsah zprávy, která funkci aktivuje do nové zprávy v jiné frontě.

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

Hodnoty přiřazené výstupním vazbám se zapisují při ukončení funkce. Ve funkci můžete použít více než jednu výstupní vazbu tak, že jednoduše přiřadíte hodnoty více výstupním parametrům.

Články s referenčními informacemi o vazbách (například fronty služby Storage) vysvětlují, které typy parametrů můžete použít s atributy triggeru, vstupu nebo výstupní vazby.

Příklad vazeb výrazů

Následující kód získá název fronty pro monitorování z nastavení aplikace a získá čas vytvoření zprávy fronty v parametru insertionTime .

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

Automaticky generované function.json

Proces sestavení vytvoří soubor function.json ve složce funkce ve složce sestavení. Jak už jsme si poznamenali dříve, tento soubor není určený k přímému úpravě. Konfiguraci vazby nemůžete změnit ani zakázat funkci úpravou tohoto souboru.

Účelem tohoto souboru je poskytnout kontroleru škálování informace, které bude používat k rozhodování o škálování plánu Consumption. Z tohoto důvodu soubor obsahuje pouze informace o triggeru, nikoli vstupní a výstupní vazby.

Vygenerovaný soubor function.json obsahuje configurationSource vlastnost, která modulu runtime říká, aby pro vazby používal atributy .NET, a ne pro konfiguraci function.json . Tady je příklad:

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

Generování function.json souborů provádí balíček NuGet Microsoft.NET.Sdk.Functions.

Následující příklad ukazuje relevantní části .csproj souborů, které mají různé cílové architektury stejného Sdk balíčku:

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

<PropertyGroup>
  <TargetFramework>net48</TargetFramework>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
</ItemGroup>

Sdk Mezi závislosti balíčku patří triggery a vazby. Projekt 1.x odkazuje na triggery a vazby 1.x, protože tyto triggery a vazby cílí na rozhraní .NET Framework, zatímco triggery 4.x a vazby cílí na .NET Core.

Balíček Sdk také závisí na Newtonsoft.Json a nepřímo na WindowsAzure.Storage. Tyto závislosti zajišťují, že váš projekt používá verze těchto balíčků, které pracují s verzí modulu runtime služby Functions, na kterou projekt cílí. Například Newtonsoft.Json má verzi 11 pro rozhraní .NET Framework 4.6.1, ale modul runtime Functions, který cílí na rozhraní .NET Framework 4.6.1, je kompatibilní pouze s Newtonsoft.Json verzí 9.0.1. Kód funkce v daném projektu tedy musí také používat Newtonsoft.Json verzi 9.0.1.

Zdrojový kód je Microsoft.NET.Sdk.Functions k dispozici v úložišti GitHubu azure-functions-vs-build-sdk.

Místní verze modulu runtime

Visual Studio používá nástroje Azure Functions Core Tools ke spouštění projektů Functions na místním počítači. Core Tools je rozhraní příkazového řádku pro modul runtime Služby Functions.

Pokud nainstalujete Nástroje Core Tools pomocí balíčku Instalační služby systému Windows (MSI) nebo pomocí npm, nemá to vliv na verzi Core Tools používanou sadou Visual Studio. Pro modul runtime Služby Functions verze 1.x sada Visual Studio ukládá verze Core Tools do složky %USERPROFILE%\AppData\Local\Azure.Functions.Cli a používá nejnovější uloženou verzi. Pro Functions 4.x jsou nástroje Core Tools součástí rozšíření Azure Functions a Web Jobs Tools . U služby Functions 1.x uvidíte, jakou verzi se používá ve výstupu konzoly při spuštění projektu Functions:

[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

Aplikaci funkcí můžete zkompilovat jako binární soubory ReadyToRun. ReadyToRun je forma předem připravené kompilace, která může zlepšit výkon spouštění, aby se snížil dopad studeného spuštění při spuštění v plánu Consumption.

ReadyToRun je k dispozici v .NET 6 a novějších verzích a vyžaduje verzi 4.0 modulu runtime Azure Functions.

Pokud chcete projekt zkompilovat jako ReadyToRun, aktualizujte soubor projektu přidáním <PublishReadyToRun> prvků a <RuntimeIdentifier> prvků. Následuje konfigurace pro publikování do 32bitové aplikace funkcí pro Windows.

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

Aplikaci můžete také sestavit pomocí ReadyToRunu z příkazového řádku. Další informace naleznete v -p:PublishReadyToRun=true dotnet publishtématu .

Podporované typy vazeb

Každá vazba má své vlastní podporované typy; Například atribut triggeru objektu blob lze použít u parametru řetězce, parametru POCO, parametru CloudBlockBlob nebo některého z několika dalších podporovaných typů. Referenční článek vazby pro vazby objektů blob obsahuje seznam všech podporovaných typů parametrů. Další informace najdete v tématu Triggery a vazby a referenční dokumenty k vazbám pro každý typ vazby.

Vazba na vrácenou hodnotu metody

Návratovou hodnotu metody pro výstupní vazbu můžete použít použitím atributu na návratovou hodnotu metody. Příklady najdete v tématu Triggery a vazby.

Návratovou hodnotu použijte pouze v případě, že úspěšné spuštění funkce vždy vede k návratové hodnotě, která se má předat výstupní vazbě. V opačném případě použijte ICollector nebo IAsyncCollector, jak je znázorněno v následující části.

Zápis více výstupních hodnot

Pokud chcete na výstupní vazbu napsat více hodnot nebo pokud úspěšné vyvolání funkce nemusí vést k předání výstupní vazby, použijte tyto ICollector nebo IAsyncCollector typy. Tyto typy jsou kolekce jen pro zápis, které jsou zapsány do výstupní vazby po dokončení metody.

Tento příklad zapíše více zpráv front do stejné fronty pomocí 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}");
    }
}

Async

Pokud chcete, aby byla funkce asynchronní, použijte async klíčové slovo a vraťte Taskobjekt.

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

Parametry nemůžete použít out v asynchronních funkcích. Pro výstupní vazby použijte místo toho návratovou hodnotu funkce nebo objekt kolektoru.

Tokeny zrušení

Funkce může přijmout parametr CancellationToken , který umožňuje operačnímu systému upozornit váš kód, když se funkce chystá ukončit. Pomocí tohoto oznámení můžete zajistit, aby se funkce neočekávaně neukončila způsobem, který ponechá data v nekonzistentním stavu.

Vezměte v úvahu případ, kdy máte funkci, která zpracovává zprávy v dávkách. Následující funkce aktivovaná službou Azure Service Bus zpracovává pole objektů ServiceBusReceivedMessage , které představují dávku příchozích zpráv, které se mají zpracovat voláním konkrétní funkce:

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

Protokolování

V kódu funkce můžete zapisovat výstup do protokolů, které se v Application Insights zobrazují jako trasování. Doporučeným způsobem zápisu do protokolů je zahrnutí parametru typu ILogger, který je obvykle pojmenován log. Verze 1.x použitého TraceWritermodulu runtime Functions, který také zapisuje do Application Insights, ale nepodporuje strukturované protokolování. Nepoužívejte Console.Write k zápisu protokolů, protože tato data nezachytává Application Insights.

ILogger

Do definice funkce zahrňte parametr ILogger , který podporuje strukturované protokolování.

U objektu voláte Log<level> rozšiřující metody v ILoggeru ILogger k vytvoření protokolů. Následující kód zapíše protokoly Information s 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);

Další informace o tom, jak služba Functions implementuje ILogger, najdete v tématu Shromažďování telemetrických dat. Kategorie s předponou Function předpokládejme, že používáte ILogger instanci. Pokud se rozhodnete místo toho použít ILogger<T>, název kategorie může být založen na T.

Strukturované protokolování

Pořadí zástupných symbolů, nikoli jejich názvů, určuje, které parametry se použijí ve zprávě protokolu. Předpokládejme, že máte následující kód:

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

Pokud zachováte stejný řetězec zprávy a obrátíte pořadí parametrů, bude výsledný text zprávy obsahovat hodnoty na nesprávných místech.

Zástupné symboly se zpracovávají tímto způsobem, abyste mohli provádět strukturované protokolování. Application Insights ukládá páry název-hodnota parametru a řetězec zprávy. Výsledkem je, že argumenty zprávy se stanou poli, na která se můžete dotazovat.

Pokud volání metody logger vypadá jako v předchozím příkladu, můžete dotazovat pole customDimensions.prop__rowKey. Předpona prop__ se přidá, aby nedošlo ke kolizi mezi poli, která modul runtime přidá, a pole, která kód funkce přidá.

Můžete také zadat dotaz na původní řetězec zprávy odkazováním na pole customDimensions.prop__{OriginalFormat}.

Tady je ukázková reprezentace customDimensions dat JSON:

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

Protokolování vlastní telemetrie

Existuje verze sady Application Insights SDK specifická pro funkce, kterou můžete použít k odesílání vlastních telemetrických dat z funkcí do Application Insights: Microsoft.Azure.WebJobs.Logging.ApplicationInsights. K instalaci tohoto balíčku použijte následující příkaz z příkazového řádku:

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

Install-Package Microsoft.Azure.WebJobs.Logging.ApplicationInsights -Version <VERSION>

V tomto příkazu nahraďte <VERSION> verzí tohoto balíčku, která podporuje vaši nainstalovanou verzi Microsoft.Azure.WebJobs.

Následující příklady jazyka C# používají vlastní rozhraní API telemetrie. Příklad je pro knihovnu tříd .NET, ale kód Application Insights je stejný pro skript jazyka C#.

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

using System;
using System.Net;
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.Azure.WebJobs;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;
using System.Linq;

namespace functionapp0915
{
    public static class HttpTrigger2
    {
        private static string key = TelemetryConfiguration.Active.InstrumentationKey = 
            System.Environment.GetEnvironmentVariable(
                "APPINSIGHTS_INSTRUMENTATIONKEY", EnvironmentVariableTarget.Process);

        private static TelemetryClient telemetryClient = 
            new TelemetryClient() { InstrumentationKey = key };

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

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

            // Get request body
            dynamic data = await req.Content.ReadAsAsync<object>();

            // Set name to query string or body data
            name = name ?? data?.name;
         
            // Track an Event
            var evt = new EventTelemetry("Function called");
            UpdateTelemetryContext(evt.Context, context, name);
            telemetryClient.TrackEvent(evt);
            
            // Track a Metric
            var metric = new MetricTelemetry("Test Metric", DateTime.Now.Millisecond);
            UpdateTelemetryContext(metric.Context, context, name);
            telemetryClient.TrackMetric(metric);
            
            // Track a Dependency
            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
            };
            UpdateTelemetryContext(dependency.Context, context, name);
            telemetryClient.TrackDependency(dependency);
        }
        
        // Correlate all telemetry with the current Function invocation
        private static void UpdateTelemetryContext(TelemetryContext context, ExecutionContext functionContext, string userName)
        {
            context.Operation.Id = functionContext.InvocationId.ToString();
            context.Operation.ParentId = functionContext.InvocationId.ToString();
            context.Operation.Name = functionContext.FunctionName;
            context.User.Id = userName;
        }
    }    
}

Nevolejte TrackRequest nebo StartOperation<RequestTelemetry> protože se zobrazí duplicitní žádosti o vyvolání funkce. Modul runtime služby Functions automaticky sleduje požadavky.

Nenastavujte telemetryClient.Context.Operation.Id. Toto globální nastavení způsobí nesprávnou korelaci, když je spuštěno mnoho funkcí současně. Místo toho vytvořte novou instanci telemetrie (DependencyTelemetry, EventTelemetry) a upravte její Context vlastnost. Pak předejte instanci telemetrie odpovídající Track metodě TelemetryClient (TrackDependency(), TrackEvent(), TrackMetric()). Tato metoda zajišťuje, že telemetrie obsahuje správné podrobnosti korelace pro vyvolání aktuální funkce.

Testování funkcí

Následující články ukazují, jak spustit funkci knihovny tříd C# v procesu místně pro účely testování:

• Visual Studio
• Visual Studio Code
• Příkazový řádek

Proměnné prostředí

Pokud chcete získat proměnnou prostředí nebo hodnotu nastavení aplikace, použijte System.Environment.GetEnvironmentVariable, jak je znázorněno v následujícím příkladu kódu:

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

Nastavení aplikace je možné číst z proměnných prostředí při místním vývoji i při spuštění v Azure. Při místním vývoji pocházejí nastavení aplikace z Values kolekce v souboru local.settings.json . V obou prostředích, v místním prostředí i v Azure načte GetEnvironmentVariable("<app setting name>") hodnotu pojmenovaného nastavení aplikace. Když například spouštíte místně, vrátí se "Název osobního webu", pokud váš local.settings.json soubor obsahuje { "Values": { "WEBSITE_SITE_NAME": "My Site Name" } }.

Vlastnost System.Configuration.ConfigurationManager.AppSettings je alternativním rozhraním API pro získání hodnot nastavení aplikace, ale doporučujeme použít, GetEnvironmentVariable jak je znázorněno zde.

Vazba za běhu

V jazyce C# a dalších jazycích .NET můžete na rozdíl od deklarativních vazeb v atributech použít imperativní vzor vazby. Imperativní vazba je užitečná v případě, že parametry vazby je potřeba vypočítat za běhu místo doby návrhu. Pomocí tohoto vzoru můžete vytvořit vazbu na podporované vstupní a výstupní vazby v kódu funkce.

Nadefinujte imperativní vazbu následujícím způsobem:

• Nezahrnujte do podpisu funkce atribut pro požadované imperativní vazby.

• Předání vstupního parametru Binder binder nebo IBinder binder.

• K provedení datové vazby použijte následující vzor jazyka C#.

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

  BindingTypeAttribute je atribut .NET, který definuje vaši vazbu a T je vstupním nebo výstupním typem, který tento typ vazby podporuje. T nemůže být typ parametru out (například out JObject). Výstupní vazba tabulky Mobile Apps například podporuje šest typů výstupu, ale s imperativní vazbou můžete použít pouze ICollector<T> nebo IAsyncCollector<T>.

Příklad s jedním atributem

Následující příklad kódu vytvoří výstupní vazbu objektu blob služby Storage s cestou objektu blob definovanou za běhu a pak zapíše řetězec do objektu 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 definuje vstupní nebo výstupní vazbu objektu blob služby Storage a TextWriter je podporovaný typ výstupní vazby.

Příklad více atributů

Předchozí příklad získá nastavení aplikace pro hlavní účet úložiště aplikace funkcí připojovací řetězec (což je AzureWebJobsStorage). Vlastní nastavení aplikace, které se má použít pro účet úložiště, můžete zadat přidáním atributu StorageAccountAttribute a předáním pole atributů do BindAsync<T>(). Binder Použijte parametr, nikoli IBinder. Příklad:

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

Triggery a vazby

Tato tabulka ukazuje vazby podporované v hlavních verzích modulu runtime Azure Functions:

Poznámky:

1. Podpora pro modul runtime Azure Functions verze 1.x skončí 14. září 2026. Důrazně doporučujeme migrovat aplikace na verzi 4.x , abyste měli plnou podporu.
2. Počínaje modulem runtime verze 2.x musí být zaregistrovány všechny vazby s výjimkou http a časovače. Viz Registrace rozšíření vazeb.
3. Triggery nejsou v plánu Consumption podporované. Vyžaduje triggery řízené modulem runtime.
4. Podporováno pouze v režimech Kubernetes, IoT Edge a dalších režimech v místním prostředí.

Další kroky