Megosztás a következőn keresztül:

Útmutató a C# Azure Functions izolált feldolgozói modellben való futtatásához

  • Cikk

Ez a cikk bemutatja az Azure Functions .NET-ben való használatát az izolált feldolgozói modell használatával. Ez a modell lehetővé teszi, hogy a projekt más futtatókörnyezeti összetevőktől függetlenül megcélozza a .NET verzióit. A támogatott .NET-verziókról további információt a támogatott verzióban talál.

Az alábbi hivatkozások segítségével azonnal megkezdheti a .NET izolált feldolgozómodell-függvények létrehozásának megkezdését.

Első lépések Fogalmak Példák

Az izolált feldolgozómodell-projekt Azure-ban való üzembe helyezéséről az Üzembe helyezés az Azure Functionsben című témakörben olvashat.

Az izolált feldolgozói modell előnyei

A .NET-osztálytárfüggvények kétféleképpen futtathatók: vagy ugyanabban a folyamatban , mint a Functions gazdagép futtatókörnyezete (folyamatban) vagy egy izolált feldolgozófolyamatban. Ha a .NET-függvények izolált feldolgozófolyamatban futnak, az alábbi előnyöket használhatja ki:

  • Kevesebb ütközés: Mivel a függvények külön folyamatban futnak, az alkalmazásban használt szerelvények nem ütköznek a gazdafolyamat által használt szerelvények különböző verzióival.
  • A folyamat teljes vezérlése: Ön szabályozza az alkalmazás elindítását, ami azt jelenti, hogy kezelheti a használt konfigurációkat, és elindíthatja a köztes szoftvert.
  • Standard függőséginjektálás: Mivel teljes mértékben felügyeli a folyamatot, a függőséginjektáláshoz és a köztes szoftver függvényalkalmazásba való beépítéséhez használhatja az aktuális .NET-viselkedéseket.
  • .NET-verziórugalmasság: A gazdafolyamaton kívül futó függvények a Függvények futtatókörnyezet által natív módon nem támogatott .NET-verziókon futtathatók, beleértve a .NET-keretrendszer is.

Ha már rendelkezik folyamatban futó C# függvényalkalmazással, migrálnia kell az alkalmazást, hogy kihasználhassa ezeket az előnyöket. További információ: .NET-alkalmazások migrálása a folyamatban lévő modellből az izolált feldolgozói modellbe.

A két mód átfogó összehasonlítását lásd : Különbségek a folyamatban lévő és a feldolgozói folyamat elkülönítése .NET Azure Functions között.

Támogatott verziók

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

Feljegyzés

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

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

Functions futtatókörnyezet verziója Izolált feldolgozói modell Folyamatközi modell5
Functions 4.x1 .NET 9.0 (előzetes verzió)
.NET 8.0
.NET 6.02
.NET-keretrendszer 4,83		 .NET 8.0
.NET 6.02
Functions 1.x4 n.a. .NET-keretrendszer 4.8

Az 1 .NET 7 korábban támogatott volt az izolált feldolgozói modellben, de 2024. május 14-én véget ért a hivatalos támogatás .

A 2 .NET 6 2024. november 12-én véget ér a hivatalos támogatásnak .

3 A buildelési folyamathoz a .NET SDK is szükséges.

4 Az Azure Functions-futtatókörnyezet 1.x verziójának támogatása 2026. szeptember 14-én megszűnik. További információkért tekintse meg ezt a támogatási közleményt. A folyamatos teljes támogatás érdekében át kell telepítenie az alkalmazásokat a 4.x verzióra.

5 A folyamaton belüli modell támogatása 2026. november 10-én megszűnik. További információkért tekintse meg ezt a támogatási közleményt. A folyamatos teljes támogatás érdekében az alkalmazásokat át kell telepítenie az izolált feldolgozói modellbe.

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

Projektstruktúra

Az Azure Functions izolált feldolgozómodellt használó .NET-projektje alapvetően egy .NET-konzolalkalmazás-projekt, amely egy támogatott .NET-futtatókörnyezetet céloz meg. Az alábbi alapvető fájlok szükségesek minden .NET-izolált projekthez:

  • C# projektfájl (.csproj), amely meghatározza a projektet és a függőségeket.
  • Program.cs fájl, amely az alkalmazás belépési pontja.
  • A függvényeket meghatározó kódfájlok.
  • host.json fájl, amely meghatározza a projekt függvényei által megosztott konfigurációt.
  • local.settings.json fájl, amely meghatározza a projekt által a számítógépen helyi futtatáskor használt környezeti változókat.

A teljes példákért tekintse meg a .NET 8 mintaprojektet és a .NET-keretrendszer 4.8 mintaprojektet.

Csomaghivatkozások

Az Azure Functionshez készült .NET-projektek az izolált feldolgozói modellel egyedi csomagokat használnak az alapvető funkciókhoz és a kötési bővítményekhez egyaránt.

Alapcsomagok

A .NET-függvények izolált feldolgozófolyamatban való futtatásához a következő csomagok szükségesek:

2.x-es verzió (előzetes verzió)

Az alapcsomagok 2.x verziói megváltoztatják a támogatott keretrendszereket, és támogatást nyújtanak az új .NET API-khoz ezekből a későbbi verziókból. Ha a .NET 9 (előzetes verzió) vagy újabb verziót célozza meg, az alkalmazásnak mindkét csomag 2.0.0-preview1-es vagy újabb verziójára kell hivatkoznia.

A kezdeti előzetes verziók kompatibilisek az 1.x verzióra írt kóddal. Az előzetes verzió időtartama alatt azonban az újabb verziók olyan viselkedésváltozásokat vezethetnek be, amelyek befolyásolhatják az Ön által írt kódot.

A 2.x verzióra való frissítéskor jegyezze fel a következő módosításokat:

  • A 2.0.0-preview2 verziótól kezdve a Microsoft.Azure.Functions.Worker.Sdk alapértelmezett konfigurációkat ad hozzá az SDK-tárolók buildjeihez.
  • A Microsoft.Azure.Functions.Worker 2.0.0-preview2-es verziójától kezdve:
    • Ez a verzió támogatja a következőt IHostApplicationBuilder: . Ebben az útmutatóban néhány példa olyan lapokat tartalmaz, amelyek az alternatív megoldások használatát IHostApplicationBuildermutatják be. Ezekhez a példákhoz a 2.x verzió szükséges.
    • A szolgáltató hatókörének érvényesítése alapértelmezés szerint szerepel, ha fejlesztési környezetben fut. Ez a viselkedés megfelel ASP.NET Core-nak.
    • A EnableUserCodeException beállítás alapértelmezés szerint engedélyezve van. A tulajdonság már elavultként van megjelölve.
    • A IncludeEmptyEntriesInMessagePayload beállítás alapértelmezés szerint engedélyezve van. Ha ez a beállítás engedélyezve van, a gyűjteményeket ábrázoló hasznos adatok mindig üres bejegyzéseket tartalmaznak. Ha például törzs nélkül küld el egy üzenetet, az eseményindító adataiban továbbra is egy string[] üres bejegyzés jelenik meg. Az üres bejegyzések felvétele megkönnyíti a metaadat-tömbök kereszthivatkozását, amelyekre a függvény is hivatkozhat. Ezt a viselkedést letilthatja a szolgáltatáskonfigurációban való WorkerOptions beállítással.IncludeEmptyEntriesInMessagePayload false
    • Az ILoggerExtensions osztály átnevezve a következőre FunctionsLoggerExtensions: . Az átnevezés megakadályozza a nem egyértelmű híváshibát egy ILogger példány használatakorLogMetric().

Bővítménycsomagok

Mivel a .NET izolált feldolgozói folyamatfüggvényei különböző kötéstípusokat használnak, egyedi kötésbővítmény-csomagokat igényelnek.

Ezeket a bővítménycsomagokat a Microsoft.Azure.Functions.Worker.Extensions alatt találja.

Indítás és konfigurálás

Az izolált feldolgozói modell használata esetén hozzáféréssel rendelkezik a függvényalkalmazás elindításához, amely általában a függvényalkalmazásban Program.cstalálható. Ön a felelős a saját gazdagéppéldány létrehozásáért és elindításáért. Így közvetlen hozzáféréssel rendelkezik az alkalmazás konfigurációs folyamatához is. A .NET Functions izolált feldolgozói folyamatával sokkal egyszerűbben adhat hozzá konfigurációkat, injektálhat függőségeket, és saját köztes szoftvereket futtathat.

Az alábbi kód egy HostBuilder-folyamat példáját mutatja be:

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(s =>
    {
        s.AddApplicationInsightsTelemetryWorkerService();
        s.ConfigureFunctionsApplicationInsights();
        s.AddSingleton<IHttpResponderService, DefaultHttpResponderService>();
        s.Configure<LoggerFilterOptions>(options =>
        {
            // The Application Insights SDK adds a default logging filter that instructs ILogger to capture only Warning and more severe logs. Application Insights requires an explicit override.
            // Log levels can also be configured using appsettings.json. For more information, see https://learn.microsoft.com/en-us/azure/azure-monitor/app/worker-service#ilogger-logs
            LoggerFilterRule toRemove = options.Rules.FirstOrDefault(rule => rule.ProviderName
                == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");

            if (toRemove is not null)
            {
                options.Rules.Remove(toRemove);
            }
        });
    })
    .Build();

Ehhez a kódhoz szükséges using Microsoft.Extensions.DependencyInjection;.

A hívás Build() előtt a IHostBuilderkövetkezőt kell elvégeznie:

  • Hívja meg a ConfigureFunctionsWebApplication() ASP.NET Core-integrációt vagy ConfigureFunctionsWorkerDefaults() más módon. A beállításokkal kapcsolatos részletekért tekintse meg a HTTP-eseményindítót .
    Ha az alkalmazást F#-tal írja, egyes trigger- és kötéskiterjesztések további konfigurációt igényelnek. Ha ezeket a bővítményeket egy F#-alkalmazásban szeretné használni, tekintse meg a Blobs-bővítmény, a Táblák és a Cosmos DB-bővítmény beállítási dokumentációját.
  • Konfigurálja a projekt által igényelt összes szolgáltatást vagy alkalmazáskonfigurációt. Részletekért tekintse meg a Konfiguráció című témakört.
    Ha az Application Insights használatát tervezi, meg kell hívnia és ConfigureFunctionsApplicationInsights() meg kell adnia AddApplicationInsightsTelemetryWorkerService() a meghatalmazottatConfigureServices(). Részletekért tekintse meg az Application Insightst .

Ha a projekt a 4.8-as .NET-keretrendszer célozza meg, a HostBuilder létrehozása előtt hozzá kell adniaFunctionsDebugger.Enable();. Ez lehet a metódus első sora Main() . További információ: Hibakeresés a .NET-keretrendszer célzása során.

A HostBuilder egy teljesen inicializált IHost példány létrehozására és visszaadására szolgál, amelyet aszinkron módon futtat a függvényalkalmazás elindításához.

await host.RunAsync();

Konfiguráció

A használt szerkesztő típusa határozza meg, hogyan konfigurálhatja az alkalmazást.

A ConfigureFunctionsWorkerDefaults metódussal adhatja hozzá a függvényalkalmazás futtatásához szükséges beállításokat. A metódus a következő funkciókat tartalmazza:

  • Konverterek alapértelmezett készlete.
  • Állítsa be az alapértelmezett JsonSerializerOptions értéket úgy, hogy figyelmen kívül hagyja a tulajdonságneveken a burkolatot.
  • Integrálható az Azure Functions naplózásával.
  • Kimeneti kötés közbenső szoftvere és funkciói.
  • Függvényvégrehajtási köztes szoftver.
  • Alapértelmezett gRPC-támogatás.
.ConfigureFunctionsWorkerDefaults()

A gazdagépkészítő folyamathoz való hozzáférés azt jelenti, hogy az inicializálás során bármilyen alkalmazásspecifikus konfigurációt is beállíthat. A ConfigureAppConfiguration metódust meghívhatja a HostBuilderen egy vagy több alkalommal a kód által igényelt konfigurációs források hozzáadásához. Az alkalmazáskonfigurációval kapcsolatos további információkért lásd : Konfiguráció a ASP.NET Core-ban.

Ezek a konfigurációk csak a létrehozott munkavégző kódra vonatkoznak, és nem befolyásolják közvetlenül a Functions-gazdagép, illetve az eseményindítók és kötések konfigurációját. A függvények gazdagépének, eseményindítójának és kötési konfigurációjának módosításához továbbra is a host.json fájlt kell használnia.

Feljegyzés

Az egyéni konfigurációs források nem használhatók eseményindítók és kötések konfigurálásához. Az eseményindítókonfigurációnak és a kötési konfigurációnak elérhetőnek kell lennie a Functions platformon, és nem csak az alkalmazás kódjához. Ezt a konfigurációt az alkalmazásbeállítások, a Key Vault-referenciák vagy az alkalmazáskonfigurációs referenciák funkcióival adhatja meg.

Függőséginjektálás

Az izolált feldolgozó modell szabványos .NET-mechanizmusokat használ a szolgáltatások injektálására.

Amikor használ egy HostBuilderszolgáltatást, hívja meg a ConfigureServices szolgáltatást a gazdagépszerkesztőben, és használja az IServiceCollection bővítménymetszeteit adott szolgáltatások injektálásához. Az alábbi példa egy egyszeri szolgáltatásfüggőséget injektál:

.ConfigureServices(services =>
{
    services.AddSingleton<IHttpResponderService, DefaultHttpResponderService>();
})

Ehhez a kódhoz szükséges using Microsoft.Extensions.DependencyInjection;. További információ: Függőséginjektálás a ASP.NET Core-ban.

Azure-ügyfelek regisztrálása

A függőséginjektálás más Azure-szolgáltatásokkal való interakcióra használható. Az ügyfeleket a Microsoft.Extensions.Azure csomag használatával injektálhatja az Azure SDK for .NET-ből. A csomag telepítése után regisztrálja az ügyfeleket a szolgáltatásgyűjtemény Program.csmeghívásávalAddAzureClients(). Az alábbi példa egy elnevezett ügyfelet konfigurál az Azure Blobshoz:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Azure;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices((hostContext, services) =>
    {
        services.AddAzureClients(clientBuilder =>
        {
            clientBuilder.AddBlobServiceClient(hostContext.Configuration.GetSection("MyStorageConnection"))
                .WithName("copierOutputBlob");
        });
    })
    .Build();

host.Run();

Az alábbi példa bemutatja, hogyan használhatjuk ezt a regisztrációs és SDK-típust a blobtartalmak streamként való másolásához egy tárolóból egy másikba egy injektált ügyfél használatával:

using Microsoft.Extensions.Azure;
using Microsoft.Extensions.Logging;

namespace MyFunctionApp
{
    public class BlobCopier
    {
        private readonly ILogger<BlobCopier> _logger;
        private readonly BlobContainerClient _copyContainerClient;

        public BlobCopier(ILogger<BlobCopier> logger, IAzureClientFactory<BlobServiceClient> blobClientFactory)
        {
            _logger = logger;
            _copyContainerClient = blobClientFactory.CreateClient("copierOutputBlob").GetBlobContainerClient("samples-workitems-copy");
            _copyContainerClient.CreateIfNotExists();
        }

        [Function("BlobCopier")]
        public async Task Run([BlobTrigger("samples-workitems/{name}", Connection = "MyStorageConnection")] Stream myBlob, string name)
        {
            await _copyContainerClient.UploadBlobAsync(name, myBlob);
            _logger.LogInformation($"Blob {name} copied!");
        }

    }
}

Ebben ILogger<T> a példában függőséginjektálással is beszerezték, így a rendszer automatikusan regisztrálja. A naplózás konfigurációs beállításairól a Naplózás című témakörben olvashat bővebben.

Tipp.

A példa egy literális sztringet használt az ügyfél nevének és Program.cs a függvénynek. Fontolja meg inkább a függvényosztályban definiált megosztott állandó sztring használatát. Hozzáadhatja, majd hivatkozhat public const string CopyStorageClientName = nameof(_copyContainerClient); BlobCopier.CopyStorageClientName például mindkét helyre. Hasonlóképpen definiálhatja a konfigurációs szakasz nevét a függvény helyett.Program.cs

Közbenső szoftver

Az izolált feldolgozói modell szintén támogatja a köztes szoftver regisztrációt a ASP.NET létezőhöz hasonló modell használatával. Ez a modell lehetővé teszi, hogy logikát injektáljon a meghívási folyamatba, valamint a függvények végrehajtása előtt és után.

A ConfigureFunctionsWorkerDefaults bővítménymetódus túlterheléssel rendelkezik, amely lehetővé teszi a saját köztes szoftver regisztrálását, ahogy az alábbi példában látható.

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults(workerApplication =>
    {
        // Register our custom middlewares with the worker

        workerApplication.UseMiddleware<ExceptionHandlingMiddleware>();

        workerApplication.UseMiddleware<MyCustomMiddleware>();

        workerApplication.UseWhen<StampHttpHeaderMiddleware>((context) =>
        {
            // We want to use this middleware only for http trigger invocations.
            return context.FunctionDefinition.InputBindings.Values
                          .First(a => a.Type.EndsWith("Trigger")).Type == "httpTrigger";
        });
    })
    .Build();

A UseWhen bővítménymetódus egy feltételesen végrehajtott köztes szoftver regisztrálásához használható. Ehhez a metódushoz olyan predikátumot kell átadnia, amely logikai értéket ad vissza, és a köztes szoftver részt vesz a meghívás feldolgozási folyamatában, ha a predikátum visszatérési értéke .true

A FunctionContext alábbi bővítménymetódusai megkönnyítik a köztes szoftverekkel való munkát az izolált modellben.

Metódus Leírás
GetHttpRequestDataAsync Lekéri a HttpRequestData példányt, amikor egy HTTP-eseményindító meghívja. Ez a metódus egy olyan példányt ValueTask<HttpRequestData?>ad vissza, amely akkor hasznos, ha üzenetadatokat szeretne olvasni, például kérésfejléceket és cookie-kat.
GetHttpResponseData Lekéri a HttpResponseData példányt, amikor egy HTTP-eseményindító meghívja.
GetInvocationResult Lekéri az InvocationResultaktuális függvényvégrehajtás eredményét képviselő példányt. Value A tulajdonság használatával igény szerint lekérheti vagy beállíthatja az értéket.
GetOutputBindings Lekéri az aktuális függvény végrehajtásához szükséges kimeneti kötési bejegyzéseket. A metódus eredményének minden bejegyzése típus típusú OutputBindingData. A tulajdonság használatával Value igény szerint lekérheti vagy beállíthatja az értéket.
BindInputAsync Egy bemeneti kötéselem kötése a kért BindingMetadata példányhoz. Ezt a módszert például akkor használhatja, ha olyan függvényt használ, amelynek BlobInput bemeneti kötését a köztes szoftvernek kell használnia.

Ez egy példa egy köztes szoftver implementációjára, amely beolvassa a HttpRequestData példányt, és frissíti a példányt a HttpResponseData függvény végrehajtása során:

internal sealed class StampHttpHeaderMiddleware : IFunctionsWorkerMiddleware
{
    public async Task Invoke(FunctionContext context, FunctionExecutionDelegate next)
    {
        var requestData = await context.GetHttpRequestDataAsync();

        string correlationId;
        if (requestData!.Headers.TryGetValues("x-correlationId", out var values))
        {
            correlationId = values.First();
        }
        else
        {
            correlationId = Guid.NewGuid().ToString();
        }

        await next(context);

        context.GetHttpResponseData()?.Headers.Add("x-correlationId", correlationId);
    }
}

Ez a köztes szoftver ellenőrzi egy adott kérésfejléc (x-correlationId) jelenlétét, és ha jelen van, a fejlécérték használatával bélyegzik le a válaszfejlécet. Ellenkező esetben létrehoz egy új GUID-értéket, és ezt használja a válaszfejléc bélyegzésével. Az egyéni köztes szoftver függvényalkalmazásban való használatára vonatkozó teljesebb példáért tekintse meg az egyéni köztes szoftver referenciamintáját.

JSON-szerializálás testreszabása

Az izolált feldolgozó modell alapértelmezés szerint használ System.Text.Json . A szerializáló viselkedését testre szabhatja úgy, hogy a fájl részeként konfigurálja a Program.cs szolgáltatásokat. Ez a szakasz az általános célú szerializálást ismerteti, és nem befolyásolja a HTTP-eseményindító JSON-szerializálását ASP.NET Core-integrációval, amelyet külön kell konfigurálni.

Az alábbi példa ezt ConfigureFunctionsWebApplicationmutatja be, de a következőhöz ConfigureFunctionsWorkerDefaultsis használható:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication((IFunctionsWorkerApplicationBuilder builder) =>
    {
        builder.Services.Configure<JsonSerializerOptions>(jsonSerializerOptions =>
        {
            jsonSerializerOptions.PropertyNamingPolicy = JsonNamingPolicy.CamelCase;
            jsonSerializerOptions.DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull;
            jsonSerializerOptions.ReferenceHandler = ReferenceHandler.Preserve;

            // override the default value
            jsonSerializerOptions.PropertyNameCaseInsensitive = false;
        });
    })
    .Build();

host.Run();

Érdemes lehet inkább a szerializáláshoz JSON.NET (Newtonsoft.Json) használni. Ehhez telepítenie kell a Microsoft.Azure.Core.NewtonsoftJson csomagot. Ezután a szolgáltatásregisztrációban újból hozzárendeli a Serializer tulajdonságot a WorkerOptions konfigurációhoz. Az alábbi példa ezt ConfigureFunctionsWebApplicationmutatja be, de a következőhöz ConfigureFunctionsWorkerDefaultsis használható:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication((IFunctionsWorkerApplicationBuilder builder) =>
    {
        builder.Services.Configure<WorkerOptions>(workerOptions =>
        {
            var settings = NewtonsoftJsonObjectSerializer.CreateJsonSerializerSettings();
            settings.ContractResolver = new CamelCasePropertyNamesContractResolver();
            settings.NullValueHandling = NullValueHandling.Ignore;

            workerOptions.Serializer = new NewtonsoftJsonObjectSerializer(settings);
        });
    })
    .Build();

host.Run();

Függvényként felismert metódusok

A függvénymetódus egy nyilvános osztály nyilvános metódusa, amely a metódusra alkalmazott attribútummal Function és egy bemeneti paraméterre alkalmazott triggerattribútummal rendelkezik, ahogyan az alábbi példában látható:

[Function(nameof(QueueFunction))]
[QueueOutput("output-queue")]
public string[] Run([QueueTrigger("input-queue")] Album myQueueItem, FunctionContext context)

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

Az Function attribútum függvénybejegyzési pontként jelöli meg a metódust. A névnek egyedinek kell lennie egy projekten belül, betűvel kell kezdődnie, és csak betűket, _számokat és -legfeljebb 127 karakter hosszúságú karaktereket kell tartalmaznia. A projektsablonok gyakran létrehoznak egy metódust, Runde a metódus neve bármilyen érvényes C# metódusnév lehet. A metódusnak nyilvános osztály nyilvános tagjának kell lennie. Általában példánymetódusnak kell lennie, hogy a szolgáltatások függőséginjektáláson keresztül továbbíthatók legyenek.

Függvényparaméterek

Íme néhány paraméter, amelyet a függvénymetódus-aláírás részeként megadhat:

Végrehajtás környezete

A .NET izolált függvénykontext objektumot ad át a függvénymetódusnak. Ez az objektum lehetővé teszi, hogy egy ILogger példányt lekérjen a naplókba a GetLogger metódus meghívásával és egy sztring categoryName beírásával. Ezzel a környezettel függőséginjektálás nélkül szerezhet be egy ILogger ilyen környezetet. További információ: Naplózás.

Lemondási jogkivonatok

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

A lemondási jogkivonatok támogatottak a .NET-függvényekben, ha izolált feldolgozói folyamatban futnak. Az alábbi példa kivételt jelez a lemondási kérelem érkezésekor:

[Function(nameof(ThrowOnCancellation))]
public async Task ThrowOnCancellation(
    [EventHubTrigger("sample-workitem-1", Connection = "EventHubConnection")] string[] messages,
    FunctionContext context,
    CancellationToken cancellationToken)
{
    _logger.LogInformation("C# EventHub {functionName} trigger function processing a request.", nameof(ThrowOnCancellation));

    foreach (var message in messages)
    {
        cancellationToken.ThrowIfCancellationRequested();
        await Task.Delay(6000); // task delay to simulate message processing
        _logger.LogInformation("Message '{msg}' was processed.", message);
    }
}

Az alábbi példa törlési műveleteket hajt végre egy lemondási kérelem érkezésekor:

[Function(nameof(HandleCancellationCleanup))]
public async Task HandleCancellationCleanup(
    [EventHubTrigger("sample-workitem-2", Connection = "EventHubConnection")] string[] messages,
    FunctionContext context,
    CancellationToken cancellationToken)
{
    _logger.LogInformation("C# EventHub {functionName} trigger function processing a request.", nameof(HandleCancellationCleanup));

    foreach (var message in messages)
    {
        if (cancellationToken.IsCancellationRequested)
        {
            _logger.LogInformation("A cancellation token was received, taking precautionary actions.");
            // Take precautions like noting how far along you are with processing the batch
            _logger.LogInformation("Precautionary activities complete.");
            break;
        }

        await Task.Delay(6000); // task delay to simulate message processing
        _logger.LogInformation("Message '{msg}' was processed.", message);
    }
}

Kötések

A kötések metódusok, paraméterek és visszatérési típusok attribútumainak használatával vannak definiálva. A kötések sztringekként, tömbökként és szerializálható típusokként, például egyszerű régi osztályobjektumokként (POCO-k) biztosíthatnak adatokat. Egyes kötési bővítmények esetében a szolgáltatás SDK-kban definiált szolgáltatásspecifikus típusokhoz is csatlakozhat.

HTTP-eseményindítók esetén lásd a HTTP-eseményindító szakaszt .

A referenciaminták teljes készlete, amelyek triggereket és kötéseket használnak izolált feldolgozói folyamatfüggvényekkel, tekintse meg a kötéskiterjesztések referenciamintáját.

Bemeneti kötések

A függvények nulla vagy több bemeneti kötéssel rendelkezhetnek, amelyek adatokat továbbíthatnak egy függvénynek. Az eseményindítókhoz hasonlóan a bemeneti kötések is úgy vannak definiálva, hogy egy kötési attribútumot alkalmaznak egy bemeneti paraméterre. A függvény végrehajtásakor a futtatókörnyezet megpróbálja lekérni a kötésben megadott adatokat. A kért adatok gyakran függenek az eseményindító által a kötési paramétereket használó információktól.

Kimeneti kötések

Ha kimeneti kötésbe szeretne írni, egy kimeneti kötési attribútumot kell alkalmaznia a függvénymetódusra, amely meghatározza a kötött szolgáltatásba való írás módját. A metódus által visszaadott érték a kimeneti kötésbe lesz beírva. Az alábbi példa például egy kimeneti kötéssel elnevezett output-queue üzenetsorba ír sztringértéket:

[Function(nameof(QueueFunction))]
[QueueOutput("output-queue")]
public string[] Run([QueueTrigger("input-queue")] Album myQueueItem, FunctionContext context)
{
    // Use a string array to return more than one message.
    string[] messages = {
        $"Album name = {myQueueItem.Name}",
        $"Album songs = {myQueueItem.Songs.ToString()}"};

    _logger.LogInformation("{msg1},{msg2}", messages[0], messages[1]);

    // Queue Output messages
    return messages;
}

Több kimeneti kötés

A kimeneti kötésbe írt adatok mindig a függvény visszatérési értéke. Ha több kimeneti kötésbe kell írnia, létre kell hoznia egy egyéni visszatérési típust. Ennek a visszatérési típusnak az osztály egy vagy több tulajdonságára alkalmazott kimeneti kötési attribútummal kell rendelkeznie. Az alábbi példa egy HTTP-aktivált függvény, amely ASP.NET Core-integrációt használ, amely a HTTP-válaszra és az üzenetsor kimeneti kötésére is ír:

public class MultipleOutputBindings
{
    private readonly ILogger<MultipleOutputBindings> _logger;

    public MultipleOutputBindings(ILogger<MultipleOutputBindings> logger)
    {
        _logger = logger;
    }

    [Function("MultipleOutputBindings")]
    public MyOutputType Run([HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequest req)
    {
        _logger.LogInformation("C# HTTP trigger function processed a request.");
        var myObject = new MyOutputType
        {
            Result = new OkObjectResult("C# HTTP trigger function processed a request."),
            MessageText = "some output"
        };
        return myObject;
    }

    public class MyOutputType
    {
        [HttpResult]
        public IActionResult Result { get; set; }

        [QueueOutput("myQueue")]
        public string MessageText { get; set; }
    }
}

Ha egyéni visszatérési típusokat használ több kimeneti kötéshez ASP.NET Core-integrációval, hozzá kell adnia az [HttpResult] attribútumot az eredményt biztosító tulajdonsághoz. Az HttpResult attribútum akkor érhető el, ha az SDK 1.17.3-preview2 vagy újabb verzióját, valamint a HTTP-bővítmény 3.2.0-s vagy újabb verzióját, valamint a ASP.NET Core-bővítmény 1.3.0-s vagy újabb verzióját használja.

SDK-típusok

Egyes szolgáltatásspecifikus kötéstípusok esetében a kötési adatok szolgáltatás SDK-kból és keretrendszerekből származó típusok használatával adhatók meg. Ezek több képességet biztosítanak, mint amit egy szerializált sztring vagy egy egyszerű régi CLR-objektum (POCO) kínálhat. Az újabb típusok használatához a projektet frissíteni kell az alapfüggőségek újabb verzióinak használatához.

Dependency Verziókövetelmény
Microsoft.Azure.Functions.Worker 1.18.0 vagy újabb
Microsoft.Azure.Functions.Worker.Sdk 1.13.0 vagy újabb

Ha az SDK-típusokat helyileg teszteli a számítógépen, az Azure Functions Core Tools 4.0.5000-es vagy újabb verzióját is használnia kell. A parancs használatával ellenőrizheti az aktuális verziót func version .

Minden eseményindító és kötésbővítmény saját minimális verziókövetelményekkel is rendelkezik, amelyet a bővítményre vonatkozó referenciacikkek ismertetnek. Az alábbi szolgáltatásspecifikus kötések SDK-típusokat biztosítanak:

Szolgáltatás Eseményindító Bemeneti kötés Kimeneti kötés
Azure-blobok Általánosan elérhető Általánosan elérhető Az SDK-típusok nem ajánlottak.1
Azure-üzenetsorok Általánosan elérhető A bemeneti kötés nem létezik Az SDK-típusok nem ajánlottak.1
Azure Service Bus Általánosan elérhető A bemeneti kötés nem létezik Az SDK-típusok nem ajánlottak.1
Azure-eseményközpontok Általánosan elérhető A bemeneti kötés nem létezik Az SDK-típusok nem ajánlottak.1
Azure Cosmos DB Nem használtSDK-típusok 2 Általánosan elérhető Az SDK-típusok nem ajánlottak.1
Azure-táblák Az eseményindító nem létezik Általánosan elérhető Az SDK-típusok nem ajánlottak.1
Azure Event Grid Általánosan elérhető A bemeneti kötés nem létezik Az SDK-típusok nem ajánlottak.1

1 Olyan kimeneti forgatókönyvek esetén, amelyekben SDK-típust használna, közvetlenül kell létrehoznia és használnia az SDK-ügyfeleket a kimeneti kötés használata helyett. Lásd: Azure-ügyfelek regisztrálása függőséginjektálási példához.

2 A Cosmos DB-eseményindító az Azure Cosmos DB változáscsatornát használja, és JSON-szerializálható típusokként teszi elérhetővé a változáscsatorna elemeit. Ebben a forgatókönyvben az SDK-típusok hiánya előre meg van tervezve.

Feljegyzés

Az eseményindítók adataira támaszkodó kötési kifejezések használata esetén maga az eseményindító SDK-típusai nem használhatók.

HTTP-eseményindító

A HTTP-eseményindítók lehetővé teszik, hogy egy függvényt HTTP-kérés hívjon meg. Két különböző megközelítés használható:

  • Egy ASP.NET Core-integrációs modell , amely az ASP.NET Core-fejlesztők számára ismerős fogalmakat használja
  • Beépített modell, amely nem igényel további függőségeket, és egyéni típusokat használ HTTP-kérésekhez és válaszokhoz. Ez a megközelítés megmarad a korábbi .NET-alapú izolált feldolgozóalkalmazásokkal való visszamenőleges kompatibilitás érdekében.

ASP.NET Core-integráció

Ez a szakasz bemutatja, hogyan használható a mögöttes HTTP-kérés- és válaszobjektumok ASP.NET Core-típusok használatával, beleértve a HttpRequest, a HttpResponse és az IActionResult típusokat. Ez a modell nem érhető el a .NET-keretrendszer célzó alkalmazások számára, amelyek ehelyett a beépített modellt használják.

Feljegyzés

Az ASP.NET Core nem minden funkcióját teszi elérhetővé ez a modell. Az ASP.NET Core köztes szoftverfolyamat és útválasztási képességek nem érhetők el. ASP.NET Core-integrációhoz frissített csomagokat kell használnia.

A HTTP-hez készült ASP.NET Core-integráció engedélyezése:

  1. Adjon hozzá egy hivatkozást a projekthez a Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore csomag 1.0.0-s vagy újabb verziójához.

  2. Frissítse a projektet az alábbi csomagverziók használatára:

  3. Program.cs A fájlban frissítse a gazdagépszerkesztő konfigurációját a híváshozConfigureFunctionsWebApplication(). Ez akkor lép ConfigureFunctionsWorkerDefaults() fel, ha egyébként ezt a módszert használná. Az alábbi példa egy minimális beállítást mutat be más testreszabások nélkül:

    using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .Build();

host.Run();

  4. Frissítse a meglévő HTTP-aktivált függvényeket a ASP.NET Core-típusok használatára. Ez a példa egy egyszerű "hello, world" függvény szabványát HttpRequest és IActionResult használatát mutatja be:

    [Function("HttpFunction")]
public IActionResult Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get")] HttpRequest req)
{
    return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
}

JSON-szerializálás ASP.NET Core-integrációval

ASP.NET Core saját szerializálási réteggel rendelkezik, és az általános szerializálási konfiguráció testreszabása nem befolyásolja. A HTTP-eseményindítók szerializálási viselkedésének testreszabásához a szolgáltatásregisztráció részeként be kell vonnia egy .AddMvc() hívást. A visszaadott IMvcBuilder érték ASP.NET Core JSON-szerializálási beállításainak módosítására használható. Az alábbi példa bemutatja, hogyan konfigurálhat JSON.NET (Newtonsoft.Json) szerializáláshoz ezzel a módszerrel:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services =>
    {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
        services.AddMvc().AddNewtonsoftJson();
    })
    .Build();
host.Run();

Beépített HTTP-modell

A beépített modellben a rendszer lefordítja a bejövő HTTP-kérési üzenetet a függvénynek átadott HttpRequestData-objektumra . Ez az objektum adatokat biztosít a kérésből, beleértve Headersa , Cookies, Identities, URL, és opcionálisan egy üzenetet Body. Ez az objektum a HTTP-kérés ábrázolása, de nem kapcsolódik közvetlenül a mögöttes HTTP-figyelőhöz vagy a kapott üzenethez.

Hasonlóképpen, a függvény egy HttpResponseData objektumot ad vissza, amely a HTTP-válasz létrehozásához használt adatokat tartalmazza, beleértve az üzenetet StatusCodeis, Headersés opcionálisan egy üzenetet Body.

Az alábbi példa a következők HttpResponseDatahasználatát HttpRequestData mutatja be:

[Function(nameof(HttpFunction))]
public static HttpResponseData Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequestData req,
    FunctionContext executionContext)
{
    var logger = executionContext.GetLogger(nameof(HttpFunction));
    logger.LogInformation("message logged");

    var response = req.CreateResponse(HttpStatusCode.OK);
    response.Headers.Add("Content-Type", "text/plain; charset=utf-8");
    response.WriteString("Welcome to .NET isolated worker !!");

    return response;
}

Naplózás

Naplókba írhat egy vagy ILogger egy ILogger<T> példány használatával. A naplózó egy vagy egy ILogger<T> ILoggerFactory függőséginjektálásával szerezhető be:

public class MyFunction {
    
    private readonly ILogger<MyFunction> _logger;
    
    public MyFunction(ILogger<MyFunction> logger) {
        _logger = logger;
    }
    
    [Function(nameof(MyFunction))]
    public void Run([BlobTrigger("samples-workitems/{name}", Connection = "")] string myBlob, string name)
    {
        _logger.LogInformation($"C# Blob trigger function Processed blob\n Name: {name} \n Data: {myBlob}");
    }

}

A naplózó a függvénynek átadott FunctionContext objektumból is beszerezhető. Hívja meg a GetLogger<T> vagy a GetLogger metódust, és adjon meg egy sztringértéket, amely annak a kategóriának a neve, amelyben a naplók meg vannak írva. A kategória általában annak a függvénynek a neve, amelyből a naplók meg vannak írva. A kategóriákról a figyelési cikkből tudhat meg többet.

A különböző naplószintek ILogger<T> ILogger ( például LogWarning vagy LogError. A naplószintekről a figyelési cikkből tudhat meg többet. Szűrők regisztrálásával testre szabhatja a kódhoz hozzáadott összetevők naplószintjeit:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(services =>
    {
        // Registers IHttpClientFactory.
        // By default this sends a lot of Information-level logs.
        services.AddHttpClient();
    })
    .ConfigureLogging(logging =>
    {
        // Disable IHttpClientFactory Informational logs.
        // Note -- you can also remove the handler that does the logging: https://github.com/aspnet/HttpClientFactory/issues/196#issuecomment-432755765 
        logging.AddFilter("System.Net.Http.HttpClient", LogLevel.Warning);
    })
    .Build();

Az alkalmazás Program.cskonfigurálásának részeként azt is meghatározhatja, hogyan jelennek meg a hibák a naplókban. Az alapértelmezett viselkedés a használt szerkesztő típusától függ.

Alapértelmezés HostBuilderszerint a kód által kidobott kivételek becsomagolhatók egy RpcException. A további réteg eltávolításához állítsa a EnableUserCodeException tulajdonságot "true" értékre a szerkesztő konfigurálása során:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults(builder => {}, options =>
    {
        options.EnableUserCodeException = true;
    })
    .Build();

host.Run();

Application Insights

Az izolált folyamatalkalmazást úgy konfigurálhatja, hogy naplókat bocsátson ki közvetlenül az Application Insightsnak. Ez a viselkedés felülírja a naplók gazdagépen keresztüli átvitelének alapértelmezett viselkedését, és azért ajánlott, mert így szabályozhatja a naplók kibocsátásának módját.

Csomagok telepítése

Ha közvetlenül az Application Insightsba szeretne naplókat írni a kódból, adjon hozzá hivatkozásokat ezekre a csomagokra a projektben:

A következő parancsokat futtatva hozzáadhatja ezeket a hivatkozásokat a projekthez:

dotnet add package Microsoft.ApplicationInsights.WorkerService
dotnet add package Microsoft.Azure.Functions.Worker.ApplicationInsights

Indítás konfigurálása

Ha telepítve vannak a csomagok, a fájlban Program.cs meg kell hívnia AddApplicationInsightsTelemetryWorkerService() és ConfigureFunctionsApplicationInsights() a szolgáltatáskonfiguráció során a következő példához hasonlóan:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
    
var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

A függvények ITelemetryModuleáltal definiált ActivitySourcefüggvényeket figyelő hívás ConfigureFunctionsApplicationInsights() hozzáadása. Ez létrehozza az elosztott nyomkövetés támogatásához szükséges függőségi telemetriát. További információkért AddApplicationInsightsTelemetryWorkerService() és használatukról az Application Insights for Worker Service-alkalmazásokban olvashat.

Naplószintek kezelése

Fontos

A Functions-gazdagép és az izolált folyamatfeldolgozó külön konfigurációval rendelkezik a naplószintekhez stb. A host.json-ben lévő Application Insights-konfigurációk nem befolyásolják a feldolgozó naplózását, és hasonlóképpen a feldolgozó kódjában létrehozott konfiguráció sem befolyásolja a gazdagépről történő naplózást. Mindkét helyen alkalmaznia kell a módosításokat, ha a forgatókönyv mindkét rétegben testreszabást igényel.

Az alkalmazás többi része továbbra is együttműködik a ILogger .ILogger<T> Alapértelmezés szerint azonban az Application Insights SDK hozzáad egy naplózási szűrőt, amely arra utasítja a naplózót, hogy csak figyelmeztetéseket és súlyosabb naplózási eseményeket rögzítse. Ha le szeretné tiltani ezt a viselkedést, távolítsa el a szűrőszabályt a szolgáltatáskonfiguráció részeként:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .ConfigureLogging(logging =>
    {
        logging.Services.Configure<LoggerFilterOptions>(options =>
        {
            LoggerFilterRule defaultRule = options.Rules.FirstOrDefault(rule => rule.ProviderName
                == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
            if (defaultRule is not null)
            {
                options.Rules.Remove(defaultRule);
            }
        });
    })
    .Build();

host.Run();

Teljesítményoptimalizálás

Ez a szakasz azokat a beállításokat ismerteti, amelyek lehetővé teszik, hogy a hidegindításkor javuljon a teljesítmény.

Az alkalmazásnak általában az alapvető függőségek legújabb verzióit kell használnia. Legalább az alábbiak szerint kell frissítenie a projektet:

  1. Frissítse a Microsoft.Azure.Functions.Worker verziót az 1.19.0-s vagy újabb verzióra.
  2. Frissítse a Microsoft.Azure.Functions.Worker.Sdk-t az 1.16.4-es vagy újabb verzióra.
  3. Adjon hozzá keretrendszerhivatkozást, Microsoft.AspNetCore.Appkivéve, ha az alkalmazás .NET-keretrendszer.

Az alábbi kódrészlet egy projektfájl kontextusában jeleníti meg ezt a konfigurációt:

  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.16.4" />
  </ItemGroup>

Helyőrzők

A helyőrzők olyan platformképességek, amelyek javítják a .NET 6 vagy újabb verziót célzó alkalmazások hidegindítását. Az optimalizálás használatához explicit módon engedélyeznie kell a helyőrzőket az alábbi lépésekkel:

  1. Frissítse a projektkonfigurációt a legújabb függőségi verziók használatára az előző szakaszban leírtak szerint.

  2. Állítsa be az alkalmazásbeállítást erre az WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED az functionapp config appsettings set parancsra:1

    az functionapp config appsettings set -g <groupName> -n <appName> --settings 'WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED=1'

    Ebben a példában cserélje le <groupName> az erőforráscsoport nevére, és cserélje le <appName> a függvényalkalmazás nevére.

  3. Győződjön meg arról, hogy a netFrameworkVersion függvényalkalmazás tulajdonsága megegyezik a projekt cél-keretrendszerével, amelynek .NET 6 vagy újabb verziónak kell lennie. Ezt az az functionapp config set paranccsal teheti meg:

    az functionapp config set -g <groupName> -n <appName> --net-framework-version <framework>

    Ebben a példában cserélje le <framework> a megfelelő verziósztringet is, például v8.0a cél .NET-verziónak megfelelően.

  4. Győződjön meg arról, hogy a függvényalkalmazás egy 64 bites folyamat használatára van konfigurálva, amelyet az az functionapp config set paranccsal tehet meg:

    az functionapp config set -g <groupName> -n <appName> --use-32bit-worker-process false

Fontos

A beállításkor az WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED 1összes többi függvényalkalmazás-konfigurációt helyesen kell beállítani. Ellenkező esetben előfordulhat, hogy a függvényalkalmazás nem indul el.

Optimalizált végrehajtó

A függvény-végrehajtó a platform azon összetevője, amely meghívásokat okoz. Az összetevő optimalizált verziója alapértelmezés szerint engedélyezve van az SDK 1.16.2-es verziójától kezdve. Nincs szükség más konfigurációra.

ReadyToRun

A függvényalkalmazást ReadyToRun bináris fájlokként fordíthatja le. A ReadyToRun egy olyan idő előtti összeállítási forma, amely javíthatja az indítási teljesítményt, hogy csökkentse a hidegindítások hatását a használatalapú csomagban való futtatáskor. A ReadyToRun a .NET 6-os és újabb verzióiban érhető el, és az Azure Functions-futtatókörnyezet 4.0-s vagy újabb verzióját igényli.

A ReadyToRun megköveteli, hogy a projektet az üzemeltetési alkalmazás futtatókörnyezeti architektúrája alapján hozza létre. Ha ezek nincsenek igazítva, az alkalmazás indításkor hibaüzenet jelenik meg. Válassza ki a futtatókörnyezet azonosítóját ebből a táblából:

Operációs rendszer Az alkalmazás 32 bites1 Futtatókörnyezet azonosítója
Windows Igaz win-x86
Windows Hamis win-x64
Linux Igaz N/A (nem támogatott)
Linux Hamis linux-x64

1 Csak a 64 bites alkalmazások jogosultak más teljesítményoptimalizálásokra.

Annak ellenőrzéséhez, hogy a Windows-alkalmazás 32 bites vagy 64 bites-e, futtassa a következő CLI-parancsot az erőforráscsoport nevével és <app_name> az alkalmazás nevével helyettesítve<group_name>. Az "igaz" kimenet azt jelzi, hogy az alkalmazás 32 bites, a "false" pedig 64 bites.

 az functionapp config show -g <group_name> -n <app_name> --query "use32BitWorkerProcess"

Az alkalmazást 64 bitesre módosíthatja a következő paranccsal, ugyanazokkal a helyettesítésekkel:

az functionapp config set -g <group_name> -n <app_name> --use-32bit-worker-process false`

A projekt ReadyToRunként való fordításához frissítse a projektfájlt az elemek és <RuntimeIdentifier> az <PublishReadyToRun> elemek hozzáadásával. Az alábbi példa egy Windows 64 bites függvényalkalmazásban való közzététel konfigurációját mutatja be.

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

Ha nem szeretné beállítani a <RuntimeIdentifier> projektfájl részeként, ezt a közzétételi kézmozdulat részeként is konfigurálhatja. Windows 64 bites függvényalkalmazás esetén például a .NET CLI parancs a következő:

dotnet publish --runtime win-x64

A Visual Studióban a közzétételi profil Cél futtatókörnyezet beállításának a megfelelő futtatókörnyezet-azonosítóra kell állítania. Ha a Portable alapértelmezett értékére van állítva, a ReadyToRun nincs használatban.

Üzembe helyezés az Azure Functionsben

Amikor üzembe helyezi a függvénykódprojektet az Azure-ban, annak függvényalkalmazásban vagy Linux-tárolóban kell futnia. A függvényalkalmazásnak és más szükséges Azure-erőforrásoknak létezniük kell a kód üzembe helyezése előtt.

A függvényalkalmazást Linux-tárolóban is üzembe helyezheti. További információ: A tárolók és az Azure Functions használata.

Azure-erőforrások létrehozása

A függvényalkalmazást és más szükséges erőforrásokat az Azure-ban az alábbi módszerek egyikével hozhatja létre:

  • Visual Studio: A Visual Studio a kód közzétételi folyamata során hozhat létre erőforrásokat.
  • Visual Studio Code: A Visual Studio Code csatlakozhat az előfizetéséhez, létrehozhatja az alkalmazáshoz szükséges erőforrásokat, majd közzéteheti a kódot.
  • Azure CLI: Az Azure CLI használatával létrehozhatja a szükséges erőforrásokat az Azure-ban.
  • Azure PowerShell: Az Azure PowerShell használatával létrehozhatja a szükséges erőforrásokat az Azure-ban.
  • Üzembe helyezési sablonok: ARM-sablonok és Bicep-fájlok használatával automatizálhatja a szükséges erőforrások Azure-ba való üzembe helyezését. Győződjön meg arról, hogy a sablon tartalmazza a szükséges beállításokat.
  • Azure Portal: Létrehozhatja a szükséges erőforrásokat az Azure Portalon.

Az alkalmazás közzététele

Miután létrehozta a függvényalkalmazást és más szükséges erőforrásokat az Azure-ban, az alábbi módszerek egyikével telepítheti a kódprojektet az Azure-ban:

További információ: Üzembehelyezési technológiák az Azure Functionsben.

Üzembe helyezés hasznos adatai

Számos üzembehelyezési módszer zip-archívumot használ. Ha saját maga hozza létre a zip archívumot, annak az ebben a szakaszban ismertetett struktúrát kell követnie. Ha nem, előfordulhat, hogy az alkalmazás indításkor hibákba ütközik.

Az üzembe helyezés hasznos adatainak meg kell egyezniük egy dotnet publish parancs kimenetével, de a szülőmappa nélkül. A zip archívumot a következő fájlokból kell készíteni:

  • .azurefunctions/
  • extensions.json
  • functions.metadata
  • host.json
  • worker.config.json
  • A projekt végrehajtható (konzolalkalmazás)
  • A végrehajtható fájlokkal és könyvtárakval társviszonyban lévő egyéb fájlok és könyvtárak

Ezeket a fájlokat a buildelési folyamat hozza létre, és nem közvetlenül kell szerkeszteni őket.

A zip-archívum üzembe helyezésre való előkészítésekor csak a kimeneti könyvtár tartalmát kell tömörítenie, magát a könyvtárat nem. Az archívum aktuális munkakönyvtárba való kinyerésekor a fent felsorolt fájloknak azonnal láthatónak kell lenniük.

Üzembe helyezési követelmények

A .NET-függvények azure-beli izolált feldolgozói modellben való futtatására az operációs rendszertől függően van néhány követelmény:

  • FUNCTIONS_WORKER_RUNTIME értékét a következő értékre kell állítani: dotnet-isolated.
  • A netFrameworkVersion-t a kívánt verzióra kell állítani.

Amikor az előző szakaszban ismertetett módszerekkel hozza létre a függvényalkalmazást az Azure-ban, ezek a szükséges beállítások lesznek hozzáadva Önhöz. Amikor arm-sablonokkal vagy Bicep-fájlokkal hozza létre ezeket az erőforrásokat automatizáláshoz, mindenképpen be kell állítania őket a sablonban.

Hibakeresés

Ha helyileg fut a Visual Studio vagy a Visual Studio Code használatával, a szokásos módon hibakeresést végezhet az izolált .NET-feldolgozó projektben. Két hibakeresési forgatókönyv azonban nem a várt módon működik.

Távoli hibakeresés a Visual Studióval

Mivel az izolált feldolgozófolyamat-alkalmazás a Functions-futtatókörnyezeten kívül fut, a távoli hibakeresőt külön folyamathoz kell csatolnia. A Visual Studio használatával végzett hibakeresésről további információt a Távoli hibakeresés című témakörben talál.

Hibakeresés .NET-keretrendszer

Ha az elkülönített projekt a 4.8-as .NET-keretrendszer célozza meg, az aktuális előzetes verzió hatóköre manuális lépéseket igényel a hibakeresés engedélyezéséhez. Ezek a lépések nem szükségesek egy másik cél-keretrendszer használata esetén.

Az alkalmazás első műveleteként hívással FunctionsDebugger.Enable(); kell kezdődnie. Ez a metódusban történik a Main() HostBuilder inicializálása előtt. A Program.cs fájlnak a következőhöz hasonlóan kell kinéznie:

using System;
using System.Diagnostics;
using Microsoft.Extensions.Hosting;
using Microsoft.Azure.Functions.Worker;
using NetFxWorker;

namespace MyDotnetFrameworkProject
{
    internal class Program
    {
        static void Main(string[] args)
        {
            FunctionsDebugger.Enable();

            var host = new HostBuilder()
                .ConfigureFunctionsWorkerDefaults()
                .Build();

            host.Run();
        }
    }
}

Ezután manuálisan kell csatolnia a folyamathoz egy .NET-keretrendszer hibakereső használatával. A Visual Studio még nem teszi meg automatikusan az izolált feldolgozói folyamat .NET-keretrendszer alkalmazások esetében, és el kell kerülni a "Hibakeresés indítása" műveletet.

A projektkönyvtárban (vagy annak build kimeneti könyvtárában) futtassa a következőt:

func host start --dotnet-isolated-debug

Ezzel elindítja a feldolgozót, és a folyamat a következő üzenettel leáll:

Azure Functions .NET Worker (PID: <process id>) initialized in debug mode. Waiting for debugger to attach...

Hol <process id> található a feldolgozói folyamat azonosítója. Mostantól manuálisan is csatolhatja a folyamatot a Visual Studióval. A művelettel kapcsolatos utasításokért lásd : Hogyan csatolható egy futó folyamathoz.

A hibakereső csatolása után a folyamat végrehajtása folytatódik, és ön képes lesz a hibakeresésre.

.NET-verziók előzetes verziója

Az általánosan elérhető kiadás előtt előfordulhat, hogy a .NET-verzió előzetes verzióban vagy Go-live állapotban jelenik meg. Az állapotokkal kapcsolatos részletekért tekintse meg a .NET hivatalos támogatási szabályzatát .

Előfordulhat, hogy egy helyi Functions-projekt egy adott kiadását meg lehet célozni, az Azure-ban üzemeltetett függvényalkalmazások esetében előfordulhat, hogy ez a kiadás nem érhető el. Az Azure Functions csak az ebben a szakaszban ismertetett előzetes verziójú vagy Go-live kiadásokkal használható.

Az Azure Functions jelenleg a következő "Előzetes verzió" vagy a "Go-live" .NET-kiadással használható:

Operációs rendszer .NET előzetes verzió
Windows .NET 9 Előzetes verzió 61, 2
Linux .NET 9 RC21, 3

1 A .NET 9 sikeres célzásához a projektnek hivatkoznia kell az alapcsomagok 2.x verziójára. A Visual Studio használata esetén a .NET 9 használatához a 17.12-es vagy újabb verzió szükséges.

2 Előfordulhat, hogy a Windows támogatása egyes ügyfeleknél nem jelenik meg az előzetes verziós időszakban.

A 3 .NET 9 még nem támogatott a Flex Consumption termékváltozatban.

Az általánosan elérhető kiadások listáját a Támogatott verziók című témakörben találja.

Előzetes verziójú .NET SDK használata

Ha az Azure Functionst a .NET előzetes verziójával szeretné használni, frissítenie kell a projektet a következővel:

  1. A megfelelő .NET SDK-verzió telepítése a fejlesztés során
  2. A TargetFramework beállítás módosítása a .csproj fájlban

Amikor üzembe helyezi a függvényalkalmazást az Azure-ban, gondoskodnia kell arról is, hogy a keretrendszer elérhetővé legyen téve az alkalmazás számára. Az előzetes verzió időszakában előfordulhat, hogy egyes eszközök és szolgáltatások nem jelenik meg az új előzetes verzióban lehetőségként. Ha nem látja az Azure Portal előzetes verzióját, használhatja például a REST API-t, a Bicep-sablonokat vagy az Azure CLI-t a verzió manuális konfigurálásához.

Windows rendszeren üzemeltetett alkalmazások esetén használja az alábbi Azure CLI-parancsot. Cserélje le <groupName> az erőforráscsoport nevére, és cserélje le <appName> a függvényalkalmazás nevére. Cserélje le <framework> a megfelelő verziósztringre, például v8.0.

az functionapp config set -g <groupName> -n <appName> --net-framework-version <framework>

Megfontolandó szempontok a .NET előzetes verzióinak használatához

Tartsa szem előtt ezeket a szempontokat, amikor a Functionst a .NET előzetes verziójával használja:

  • Amikor függvényeket készít a Visual Studióban, a Visual Studio Preview-t kell használnia, amely támogatja az Azure Functions-projektek .NET előzetes verziójú SDK-kkal történő készítését.

  • Győződjön meg arról, hogy rendelkezik a legújabb Functions-eszközökkel és -sablonokkal. Az eszközök frissítése:

    1. Lépjen az Eszközök>beállításai elemre, és válassza az Azure Functions lehetőséget a Projektek és megoldások területen.
    2. Válassza a Frissítések keresése lehetőséget, és telepítse a frissítéseket a kérésnek megfelelően.

  • Az előzetes verziójú időszakban előfordulhat, hogy a fejlesztői környezet a .NET-előzetes verzió újabb verziójával rendelkezik, mint az üzemeltetett szolgáltatás. Ez azt okozhatja, hogy a függvényalkalmazás üzembe helyezése sikertelen lesz. Ennek megoldásához megadhatja az SDK azon verzióját, amelyben global.jsonhasználni szeretné.

    1. Futtassa a dotnet --list-sdks parancsot, és jegyezze fel a helyi fejlesztés során jelenleg használt előzetes verziót.
    2. Futtassa a dotnet new globaljson --sdk-version <SDK_VERSION> --force parancsot, amelyben <SDK_VERSION> a helyileg használt verzió található. A rendszer például dotnet new globaljson --sdk-version dotnet-sdk-8.0.100-preview.7.23376.3 --force a .NET 8 Preview 7 SDK-t használja a projekt létrehozásakor.

Feljegyzés

Az előzetes verziójú keretrendszerek időben történő betöltése miatt a Windows rendszeren futó függvényalkalmazások a korábbi GA-verziókhoz képest megnövekedett hideg kezdési időket tapasztalhatnak.

Következő lépések

További információ az Azure Functions ajánlott eljárásairól

.NET-alkalmazások migrálása az izolált feldolgozói modellbe