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

Článek
04/07/2024

Důležité

Podpora modelu v procesu skončí 10. listopadu 2026. Důrazně doporučujeme migrovat aplikace do izolovaného modelu pracovního procesu pro plnou podporu.

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.

Důležité

Tento článek podporuje funkce knihovny tříd .NET, které běží v procesu s modulem runtime. Funkce jazyka C# můžou také běžet mimo proces a izolovat od modulu runtime Služby Functions. Model izolovaného pracovního procesu je jediným způsobem, jak v aktuálních verzích modulu runtime Functions spouštět jiné verze než LTS aplikací .NET a .NET Framework. Další informace najdete v tématu Funkce izolovaného pracovního procesu .NET. Komplexní porovnání izolovaných pracovních procesů a funkcí .NET v procesu najdete v tématu Rozdíly mezi procesem a izolovaným pracovním procesem .NET Azure Functions.

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

Začínáme	Koncepty	Učení s asistencí / ukázky
Pomocí sady Visual Studio Použití editoru Visual Studio Code Použití nástrojů příkazového řádku	Možnosti hostování Důležité informace o výkonu Vývoj sady Visual Studio Injektáž závislostí	Vytváření bezserverových aplikací Ukázky jazyka C#

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.

Poznámka:

Informace o tom, jak změnit verzi modulu runtime Functions používanou vaší aplikací funkcí, najdete v zobrazení a aktualizaci aktuální verze modulu runtime.

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

Verze modulu runtime služby Functions	Izolovaný model pracovního procesu	Model v procesu⁵
Funkce 4.x	.NET 8.0 .NET 7.0¹ .NET 6.0² .NET Framework 4.8³	.NET 6.0²
Funkce 1.x⁴	Není k dispozici	.NET Framework 4.8

¹ .NET 7 dosáhne 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.

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.

Důležité

Proces sestavení vytvoří function.json soubor pro každou funkci. Tento function.json soubor není určen k úpravám přímo. Konfiguraci vazby nemůžete změnit ani zakázat funkci úpravou tohoto souboru. Informace o zakázání funkce najdete v tématu Postup zakázání funkcí.

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:

v4.x
v1.x

<PropertyGroup>
  <TargetFramework>net6.0</TargetFramework>
  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
</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>net6.0</TargetFramework>
  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
  <PublishReadyToRun>true</PublishReadyToRun>
  <RuntimeIdentifier>win-x86</RuntimeIdentifier>
</PropertyGroup>

Důležité

Od verze .NET 6 byla přidána podpora kompilace Composite ReadyToRun. Podívejte se na omezení architektury a platformy ReadyToRun.

Aplikaci můžete také sestavit pomocí ReadyToRunu z příkazového řádku. Další informace naleznete v -p:PublishReadyToRun=truedotnet 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.

Tip

Pokud plánujete používat vazby HTTP nebo WebHook, naplánujte, aby se zabránilo vyčerpání portů, které může být způsobeno nesprávnou instancí HttpClient. Další informace najdete v tématu Správa připojení ve službě Azure Functions.

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 zapsat výstup do protokolů, které se v aplikaci Přehledy 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 aplikačního Přehledy, ale nepodporuje strukturované protokolování. Nepoužívejte Console.Write k zápisu protokolů, protože tato data nejsou zachycená aplikací Přehledy.

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 ILoggeruILogger 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í. Aplikace Přehledy 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 Přehledy SDK specifická pro funkce, kterou můžete použít k odesílání vlastních telemetrických dat z funkcí do aplikačního Přehledy: Microsoft.Azure.WebJobs.Logging.Application Přehledy. K instalaci tohoto balíčku použijte následující příkaz z příkazového řádku:

Příkaz
PowerShell

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říkladem je knihovna tříd .NET, ale kód Přehledy aplikace je stejný pro skript jazyka C#.

v4.x
v1.x

Verze 2.x a novější verze modulu runtime používají novější funkce v aplikaci Přehledy k automatické korelaci telemetrie s aktuální operací. Není nutné ručně nastavit operaci Id, ParentIdani Name pole.

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

V tomto příkladu se vlastní data metrik agregují hostitelem před odesláním do tabulky customMetrics. Další informace najdete v dokumentaci GetMetric v Přehledy aplikace.

Při místním spuštění musíte do souboru local.settings.json přidat APPINSIGHTS_INSTRUMENTATIONKEY nastavení s klíčem Přehledy aplikace.

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í:

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.App Nastavení je alternativním rozhraním API pro získání hodnot nastavení aplikace, ale doporučujeme použít jiGetEnvironmentVariable, 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:

Typ	1,x¹	2.x a vyšší²	Trigger	Vstup	Výstup
Blob Storage	✔	✔	✔	✔	✔
Azure Cosmos DB	✔	✔	✔	✔	✔
Azure Data Explorer		✔		✔	✔
Azure SQL		✔	✔	✔	✔
Dapr⁴		✔	✔	✔	✔
Event Grid	✔	✔	✔		✔
Event Hubs	✔	✔	✔		✔
HTTP a webhooky	✔	✔	✔		✔
IoT Hub	✔	✔	✔
Kafka³		✔	✔		✔
Mobile Apps	✔			✔	✔
Notification Hubs	✔				✔
Queue Storage	✔	✔	✔		✔
Redis		✔	✔
RabbitMQ³		✔	✔		✔
SendGrid	✔	✔			✔
Service Bus	✔	✔	✔		✔
SignalR		✔	✔	✔	✔
Table Storage	✔	✔		✔	✔
Časovač	✔	✔	✔
Twilio	✔	✔			✔

¹. Podpora skončí pro modul runtime Azure Functions verze 1.x 14. září 2026. Důrazně doporučujeme migrovat aplikace na verzi 4.x , abyste měli plnou podporu.

² 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.

³ Triggery nejsou v plánu Consumption podporované. Vyžaduje triggery řízené modulem runtime.

⁴ Podporováno pouze v režimech Kubernetes, IoT Edge a dalších režimech v místním prostředí.

Další kroky

Další informace o triggerech a vazbách

Další informace o osvědčených postupech pro Azure Functions

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

Podporované verze

Projekt knihovny tříd Functions

Metody rozpoznané jako funkce

Parametry podpisu metody

Výstupní vazby

Příklad vazeb výrazů

Automaticky generované function.json

Microsoft.NET.Sdk.Functions

Místní verze modulu runtime

ReadyToRun

Podporované typy vazeb

Vazba na vrácenou hodnotu metody

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

Async

Tokeny zrušení

Protokolování

ILogger

Strukturované protokolování

Protokolování vlastní telemetrie

Testování funkcí

Proměnné prostředí

Vazba za běhu

Příklad s jedním atributem

Příklad více atributů

Triggery a vazby

Další kroky

Další materiály