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

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 s modulem runtime Functions. Funkce .NET lze případně spouštět izolovaně od modulu runtime, což 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 popisuje funkce knihovny tříd .NET, které běží v procesu runtime. Funkce jazyka C# můžou také běžet mimo hlavní proces a být izolovány od modulu runtime služby Functions. Model izolovaného pracovního procesu je jediným způsobem, jak spouštět ne-LTS verze aplikací .NET a .NET Framework v aktuálních verzích modulu runtime Functions. Další informace najdete v tématu .NET izolované funkce pracovních procesů. Komplexní porovnání izolovaných pracovních procesů a funkcí .NET v procesu najdete v tématu Difference 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

Azure Functions podporuje programovací jazyky C# a C# skript. Pokud hledáte pokyny k užívání jazyka C# na portálu Azure, přečtěte si C# referenční informace pro vývojáře.

Podporované verze

Verze prostředí runtime Azure Functions podporují konkrétní verze .NET. Další informace o verzích služby Functions najdete v tématu Azure Functions přehled verzí modulu runtime. Podpora verzí také závisí na tom, jestli vaše funkce běží v rámci procesu nebo v izolovaném pracovním procesu.

Poznámka:

Informace o tom, jak změnit verzi modulu runtime Functions používanou vaší aplikací funkcí, viz jak zobrazit a aktualizovat aktuální verzi modulu runtime.

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

Verze běhového prostředí Functions Izolovaný model pracovního procesu Model v procesu4
Funkce 4.x1 .NET 105
.NET 9,0
.NET 8.0
.NET Framework 4.82		 .NET 8.0
Funkce 1.x3 Není k dispozici .NET Framework 4.8

1 .NET 6 bylo dříve podporováno na obou modelech, ale dosáhlo konce oficiální podpory 12. listopadu 2024. .NET 7 byl dříve podporován v izolovaném modelu pracovních procesů, ale dosáhl konce oficiální podpory 14. května 2024.

2 Proces sestavení také vyžaduje .NET SDK.

3 Podpora končí pro verzi 1.x modulu runtime Azure Functions 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.

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

5 V plánu Consumption nemůžete spouštět .NET 10 aplikací v Linuxu. Pokud chcete spustit v Linuxu, měli byste místo toho použít plán Flex Consumption. Podrobné pokyny k migraci najdete v tématu Migrace aplikací plánu Consumption do plánu Flex Consumption.

Pro nejnovější zprávy o verzích Azure Functions, včetně odebrání konkrétních starších podverzí, sledujte oznámení Azure App Service.

Aktualizace na cíl .NET 8

Aplikace využívající model v procesu můžou cílit na .NET 8 podle kroků uvedený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í aplikaceFUNCTIONS_WORKER_RUNTIME musí mít hodnotu "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 odkazovala na .NET 8.

Podpora pro .NET 8 stále používá verzi 4.x modulu runtime 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 version 4.4.0 nebo novější Microsoft.NET. Sdk.Functions. Pak můžete změnit hodnotu svého TargetFramework na "net8.0". Musíte také aktualizovat local.settings.json, aby obsahoval nastavení FUNCTIONS_WORKER_RUNTIME jako "dotnet" a FUNCTIONS_INPROC_NET8_ENABLED jako "1".

Následující příklad je minimální project soubor 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ásledující příklad je minimální local.settings.json soubor 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ší. Vzhledem ke změně chování v .NET 8 můžou aplikace se staršími verzemi balíčku vyvolat nejednoznačnou 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ší možnosti a vylepšení .NET 8, musíte migrovat do izolovaného modelu pracovního procesu.

Projekt knihovny tříd Functions

V Visual Studio šablona projektu Azure Functions vytvoří projekt knihovny tříd 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ý ve vaší aplikaci funkcí v Azure. Místo toho přidejte nastavení aplikace funkcí do vaší aplikace funkcí.

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ý přímo k úpravám. 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ů. Project šablony často vytvářejí metodu s názvem Run, ale název metody může být libovolný platný název metody jazyka C#. Předchozí 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. Příkladová funkce je aktivována zprávou z fronty, která je předána metodě jako parametr 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:

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í ten 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 přiřazením hodnot k více výstupním parametrům.

Články s referenčními informacemi o vazbách (například fronty úložiště) vysvětlují, které typy parametrů můžete použít s atributy vazby typu trigger, vstup nebo výstup.

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 ve frontě 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 škálovacímu kontroleru informace, které má 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 vlastnost configurationSource, 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í souboru function.json 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>

Důležité

Počínaje verzí 4.0.6517 nástroje Core Tools musí modelové projekty in-process odkazovat na verzi 4.5.0 nebo novější Microsoft.NET.Sdk.Functions. Pokud použijete starší verzi, u příkazu func start dojde k chybě.

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 .NET Framework 4.6.1, ale modul runtime Functions, který cílí na .NET Framework 4.6.1, je kompatibilní pouze s Newtonsoft.Json 9.0.1. Kód funkce v daném projektu tedy musí také používat Newtonsoft.Json verzi 9.0.1.

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

Místní verze modulu runtime

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

Pokud nainstalujete Nástroje Core Tools pomocí balíčku instalačního programu Windows (MSI) nebo pomocí npm, nebude mít vliv na verzi Core Tools používanou Visual Studio. Pro runtime Functions verze 1.x Visual Studio ukládá verze Core Tools v %USERPROFILE%\AppData\Local\Azure.Functions.Cli a používá nejnovější verzi uloženou tam. 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ředběžné kompilace, která může zlepšit výkon při spouštění, aby se snížil dopad cold-start při běhu v plánu typu Consumption.

ReadyToRun je k dispozici v .NET 6 a novějších verzích a vyžaduje version 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ásledující příklad je konfigurace pro publikování do 32bitové funkční aplikace na Windows.

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

Důležité

Počínaje .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 možnosti -p:PublishReadyToRun=true v dotnet publish.

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 vazeb objektů blob obsahuje seznam všech podporovaných typů parametrů. Další informace najdete v tématu Triggery a vazby a referenční dokumenty pro každý typ vazby.

Návod

Pokud plánujete používat vazby HTTP nebo WebHook, naplánujte vyhnout se vyčerpání portů, které může být způsobeno nesprávným instancováním HttpClient. Další informace najdete v tématu Jak spravovat připojení v 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 do výstupní vazby zapsat více hodnot nebo pokud úspěšné vyvolání funkce nemusí vést k předání výstupní vazby, použijte typy ICollector nebo IAsyncCollector. 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}");
    }
}

Asynchronní

Pokud chcete, aby byla funkce asynchronní, použijte klíčové slovo a vrátíte objekt async.

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

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

Tokeny pro 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á Azure Service Bus zpracovává pole objektů ServiceBusReceivedMessage, které představují dávku příchozích zpráv určenou ke zpracování konkrétním vyvoláním 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í

Ve vašem kódu funkce můžete zapisovat výstup do protokolů, které se v Application Insights zobrazují jako stopy. Doporučeným způsobem zápisu do protokolů je zahrnutí parametru typu ILogger, který je obvykle pojmenován log. Verze 1.x modulu Functions runtime používá TraceWriter, který také zapisuje do Application Insights, ale nepodporuje strukturované logová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í.

S objektem ILogger voláte Log<level>rozšiřující metody na ILogger pro vytvoření protokolů. Následující kód zapíše záznamy 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í tak, abyste mohli provádět strukturované logová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

Důležité

OpenTelemetry se nepodporuje pro aplikace funkcí v procesu jazyka C#. Pro izolovaný model pracovního procesu použijte místo toho exportér OpenTelemetry , což je doporučený postup pro vlastní telemetrii. Klasická sada Application Insights SDK zobrazená v této části je starší verze a nebude dostávat nové aktualizace funkcí.

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>

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 Application Insights je stejný pro skript jazyka C#.

Verze 2.x a novější verze modulu runtime používají novější funkce v Application Insights 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 Application Insights.

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

Nevolejte TrackRequest nebo StartOperation<RequestTelemetry> protože vidíte duplicitní požadavky na 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 prostředí jak místním, tak i Azure, GetEnvironmentVariable("<app setting name>") načte hodnotu pojmenovaného nastavení aplikace. Když například spouštíte místně, vrátí se "Název mé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 .NET jazycích můžete použít imperativní vzor vazby, na rozdíl od deklarativních vazeb v atributech. 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ředejte vstupní parametr 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í nebo výstupní typ podporovaný tímto typem vazby. T nemůže být typ parametru out (například out JObject). Výstupní vazba tabulky Mobile Apps například podporuje šest výstupních typů, ale můžete použít pouze ICollector<T> nebo IAsyncCollector<T> s imperativní vazbou.

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 Storage blob vstupní nebo výstupní vazbu a TextWriter je podporovaný typ výstupní vazby.

Příklad více atributů

Předchozí příklad získá nastavení aplikace pro hlavní řetězec připojení účtu úložiště funkční aplikace (což je AzureWebJobsStorage). Vlastní nastavení aplikace, které se má použít pro účet úložiště, můžete zadat přidáním 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!!");
        }
    }
}

Spouště a vazby

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

Typ 4.x1 1,x2 Spouštěč Vstup Výstup
Blob Storage ✔ ✔ ✔ ✔ ✔
Azure Cosmos DB ✔ ✔ ✔ ✔ ✔
Azure Data Explorer ✔ ✔ ✔
Azure SQL ✔ ✔ ✔ ✔
Dapr4 ✔ ✔ ✔ ✔
Event Grid ✔ ✔ ✔ ✔
Event Hubs ✔ ✔ ✔ ✔
HTTP a webové háčky ✔ ✔ ✔ ✔
IoT Hub ✔ ✔ ✔
Kafka3 ✔ ✔ ✔
Mobile Apps ✔ ✔ ✔
Protokol kontextu modelu ✔ ✔
Centra oznámení ✔ ✔
Queue Storage ✔ ✔ ✔ ✔
Redis ✔ ✔ ✔ ✔
RabbitMQ3 ✔ ✔ ✔
SendGrid ✔ ✔ ✔
Service Bus ✔ ✔ ✔ ✔
Služba Azure SignalR ✔ ✔ ✔ ✔
Table Storage ✔ ✔ ✔ ✔
Časovač ✔ ✔ ✔
Twilio ✔ ✔ ✔
  1. Zaregistrujte všechny vazby kromě HTTP a časovače. Viz Register Azure Functions rozšíření vazeb. Tento krok se nevyžaduje při použití verze 1.x modulu runtime Functions.
  2. Support končí pro verzi 1.x modulu runtime Azure Functions 14. září 2026. Migrujte své aplikace na verzi 4.x a získáte plnou podporu.
  3. V rámci plánu Consumption nejsou triggery podporovány. Tento typ vazby vyžaduje triggery řízené modulem runtime.
  4. Tento typ vazby se podporuje jenom v Kubernetes, Azure IoT Edge a dalších režimech v místním prostředí.

Další kroky

Další informace o triggerech a vazbách

Uučte se více o osvědčených postupech pro Azure Functions

  • Last updated on