Vývoj 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 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 |
---|---|---|
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 procesu4 |
---|---|---|
Funkce 4.x1 | .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. Rozhraní .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.
2 Proces sestavení také vyžaduje sadu .NET SDK.
3 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.
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.
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.
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
neboTraceWriter
(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>
Důležité
Od verze 4.0.6517 nástrojů Core Tools musí projekty modelu v procesu odkazovat na verzi 4.5.0 nebo novější .Microsoft.NET.Sdk.Functions
Pokud použijete starší verzi, func start
příkaz se zobrazí chyba.
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>
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=true
dotnet publish
té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 Task
objekt.
public static class AsyncExample
{
[FunctionName("BlobCopy")]
public static async Task RunAsync(
[BlobTrigger("sample-images/{blobName}")] Stream blobInput,
[Blob("sample-images-copies/{blobName}", FileAccess.Write)] Stream blobOutput,
CancellationToken token,
ILogger log)
{
log.LogInformation($"BlobCopy function processed.");
await blobInput.CopyToAsync(blobOutput, 4096, token);
}
}
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 TraceWriter
modulu 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>
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#.
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
, ParentId
ani 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 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.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
neboIBinder 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 aT
je vstupním nebo výstupním typem, který tento typ vazby podporuje.T
nemůže být typ parametruout
(napříkladout 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,x1 | 2.x a vyšší2 | Trigger | Vstup | Výstup |
---|---|---|---|---|---|
Blob Storage | ✔ | ✔ | ✔ | ✔ | ✔ |
Azure Cosmos DB | ✔ | ✔ | ✔ | ✔ | ✔ |
Azure Data Explorer | ✔ | ✔ | ✔ | ||
Azure SQL | ✔ | ✔ | ✔ | ✔ | |
Dapr4 | ✔ | ✔ | ✔ | ✔ | |
Event Grid | ✔ | ✔ | ✔ | ✔ | |
Event Hubs | ✔ | ✔ | ✔ | ✔ | |
HTTP a webhooky | ✔ | ✔ | ✔ | ✔ | |
IoT Hub | ✔ | ✔ | ✔ | ||
Kafka3 | ✔ | ✔ | ✔ | ||
Mobile Apps | ✔ | ✔ | ✔ | ||
Notification Hubs | ✔ | ✔ | |||
Queue Storage | ✔ | ✔ | ✔ | ✔ | |
Redis | ✔ | ✔ | |||
RabbitMQ3 | ✔ | ✔ | ✔ | ||
SendGrid | ✔ | ✔ | ✔ | ||
Service Bus | ✔ | ✔ | ✔ | ✔ | |
SignalR | ✔ | ✔ | ✔ | ✔ | |
Table Storage | ✔ | ✔ | ✔ | ✔ | |
Časovač | ✔ | ✔ | ✔ | ||
Twilio | ✔ | ✔ | ✔ |
Poznámky:
- 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.
- 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í.