Průvodce spuštěním azure Functions v C# v izolovaném pracovním modelu

Článek
01/12/2024

Tento článek představuje úvod do práce se službou Azure Functions v .NET pomocí izolovaného modelu pracovního procesu. Tento model umožňuje projektu cílit na verze .NET nezávisle na jiných komponentách modulu runtime. Informace o podporovaných verzích .NET najdete v části Podporované verze.

Pomocí následujících odkazů můžete hned začít vytvářet funkce izolovaného pracovního modelu .NET.

Začínáme	Koncepty	Ukázky
Použití editoru Visual Studio Code Použití nástrojů příkazového řádku Pomocí sady Visual Studio	Možnosti hostování Monitorování	Referenční ukázky

Další informace o nasazení projektu izolovaného modelu pracovního procesu do Azure najdete v tématu Nasazení do Azure Functions.

Výhody izolovaného modelu pracovního procesu

Existují dva režimy, ve kterých můžete spouštět funkce knihovny tříd .NET: buď ve stejném procesu jako modul runtime hostitele služby Functions (v procesu), nebo v izolovaném pracovním procesu. Když se funkce .NET spouštějí v izolovaném pracovním procesu, můžete využít následující výhody:

Méně konfliktů: Vzhledem k tomu, že vaše funkce běží v samostatném procesu, sestavení použitá v aplikaci nejsou v konfliktu s různými verzemi stejných sestavení používaných hostitelským procesem.
Úplné řízení procesu: Řídíte spuštění aplikace, což znamená, že můžete spravovat použité konfigurace a spustit middleware.
Standardní injektáž závislostí: Vzhledem k tomu, že máte úplnou kontrolu nad procesem, můžete použít aktuální chování .NET pro injektáž závislostí a začlenit middleware do vaší aplikace funkcí.
Flexibilita verze .NET: Spuštění mimo hostitelský proces znamená, že vaše funkce se můžou spouštět ve verzích .NET, které modul runtime služby Functions nativně nepodporuje, včetně rozhraní .NET Framework.

Pokud máte existující aplikaci funkcí jazyka C#, která běží v procesu, musíte aplikaci migrovat, abyste mohli tyto výhody využít. Další informace najdete v tématu Migrace aplikací .NET z modelu v procesu do izolovaného pracovního modelu.

Komplexní porovnání mezi těmito dvěma režimy najdete v tématu Rozdíly mezi procesem v procesu a izolovaným pracovním procesem .NET Azure Functions.

Podporované verze

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

Poznámka:

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

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

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

¹ .NET 7 dosáhne konce oficiální podpory 14. května 2024.
² .NET 6 dosáhne konce oficiální podpory 12. listopadu 2024.
³ Proces sestavení také vyžaduje sadu .NET SDK. ⁴ Podpora modulu runtime Azure Functions končí 1.x 14. září 2026. Další informace najdete v tomto oznámení podpory. Pokud chcete pokračovat v plné podpoře, měli byste migrovat aplikace na verzi 4.x.
⁵ Podpora modelu v procesu končí 10. listopadu 2026. Další informace najdete v tomto oznámení podpory. Pokud chcete pokračovat v plné podpoře, měli byste své aplikace migrovat do izolovaného pracovního modelu.

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

Struktura projektu

Projekt .NET pro Azure Functions využívající izolovaný model pracovního procesu je v podstatě projekt konzolové aplikace .NET, který cílí na podporovaný modul runtime .NET. Následující jsou základní soubory vyžadované v jakémkoli izolovaném projektu .NET:

Soubor projektu jazyka C# (.csproj), který definuje projekt a závislosti.
Program.cs soubor, který je vstupním bodem aplikace.
Všechny soubory kódu definující vaše funkce.
host.json soubor, který definuje konfiguraci sdílenou funkcemi v projektu.
local.settings.json soubor, který definuje proměnné prostředí používané vaším projektem při místním spuštění na počítači.

Kompletní příklady najdete v ukázkovém projektu .NET 8 a ukázkovém projektu .NET Framework 4.8.

Odkazy na balíčky

Projekt .NET pro Azure Functions využívající izolovaný model pracovního procesu používá jedinečnou sadu balíčků pro základní funkce i rozšíření vazeb.

Základní balíčky

Následující balíčky jsou potřeba ke spuštění funkcí .NET v izolovaném pracovním procesu:

Balíčky rozšíření

Vzhledem k tomu, že funkce izolovaného pracovního procesu .NET používají různé typy vazeb, vyžadují jedinečnou sadu balíčků rozšíření vazeb.

Tyto balíčky rozšíření najdete v části Microsoft.Azure.Functions.Worker.Extensions.

Spuštění a konfigurace

Při použití izolovaných funkcí .NET máte přístup ke spuštění aplikace funkcí, která je obvykle v Program.cs. Zodpovídáte za vytváření a spouštění vlastní instance hostitele. V takovém případě máte také přímý přístup ke konfiguračnímu kanálu pro vaši aplikaci. S izolovaným pracovním procesem .NET Functions můžete mnohem snadněji přidávat konfigurace, vkládat závislosti a spouštět vlastní middleware.

Následující kód ukazuje příklad kanálu HostBuilder :

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

Tento kód vyžaduje using Microsoft.Extensions.DependencyInjection;.

Před voláním Build() na tuto možnost HostBuilderbyste měli:

Volejte buď ConfigureFunctionsWebApplication() pomocí integrace ASP.NET Core , nebo ConfigureFunctionsWorkerDefaults() jinak. Podrobnosti o těchto možnostech najdete v triggeru HTTP.
Pokud píšete aplikaci pomocí F#, některá rozšíření triggeru a vazeb vyžadují další konfiguraci. Pokud plánujete používat tato rozšíření v aplikaci F#, podívejte se do dokumentace k nastavení rozšíření Blobs, rozšíření Tables a rozšíření Cosmos DB.
Nakonfigurujte všechny služby nebo konfiguraci aplikace, které váš projekt vyžaduje. Podrobnosti najdete v části Konfigurace .
Pokud plánujete používat Přehledy aplikace, musíte zavolat AddApplicationInsightsTelemetryWorkerService() a ConfigureFunctionsApplicationInsights() v delegátoviConfigureServices(). Podrobnosti najdete v Přehledy aplikace.

Pokud váš projekt cílí na rozhraní .NET Framework 4.8, je nutné přidat FunctionsDebugger.Enable(); také před vytvořením nástroje HostBuilder. Měl by to být první řádek vaší Main() metody. Další informace naleznete v tématu Ladění při cílení na rozhraní .NET Framework.

HostBuilder se používá k sestavení a vrácení plně inicializované IHost instance, kterou spustíte asynchronně, aby se spustila aplikace funkcí.

await host.RunAsync();

Konfigurace

Metoda ConfigureFunctionsWorkerDefaults slouží k přidání nastavení vyžadovaných pro spuštění aplikace funkcí v izolovaném pracovním procesu, který zahrnuje následující funkce:

Výchozí sada převaděčů
Nastavte výchozí JsonSerializerOptions tak, aby ignorovala velikost písmen u názvů vlastností.
Integrace s protokolováním Azure Functions
Middleware a funkce výstupní vazby
Middleware spouštění funkcí
Výchozí podpora gRPC

.ConfigureFunctionsWorkerDefaults()

Přístup ke kanálu tvůrce hostitelů znamená, že během inicializace můžete také nastavit jakékoli konfigurace specifické pro aplikaci. Metodu ConfigureAppConfiguration můžete v HostBuilderu volat jednou nebo vícekrát a přidat konfigurace vyžadované vaší aplikací funkcí. Další informace o konfiguraci aplikací najdete v tématu Konfigurace v ASP.NET Core.

Tyto konfigurace platí pro vaši aplikaci funkcí spuštěnou v samostatném procesu. Pokud chcete provést změny hostitele nebo konfigurace triggeru a vazby funkcí, musíte stále použít soubor host.json.

Poznámka:

Vlastní zdroje konfigurace nelze použít pro konfiguraci aktivačních událostí a vazeb. Konfigurace triggeru a vazby musí být dostupná pro platformu Functions, a ne jenom kód aplikace. Tuto konfiguraci můžete poskytnout prostřednictvím nastavení aplikace, odkazů služby Key Vault nebo odkazů na konfiguraci aplikací.

Injektáž závislostí

Injektáž závislostí je ve srovnání s funkcemi v procesu rozhraní .NET zjednodušená, což vyžaduje vytvoření spouštěcí třídy pro registraci služeb.

Pro aplikaci izolovaného procesu .NET použijete standardní způsob volání ConfigureServices v tvůrci hostitelů a použijete metody rozšíření v IServiceCollection k vložení konkrétních služeb.

Následující příklad vloží závislost jednoúčelové služby:

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

Tento kód vyžaduje using Microsoft.Extensions.DependencyInjection;. Další informace najdete v tématu Injektáž závislostí v ASP.NET Core.

Registrace klientů Azure

Injektáž závislostí se dá použít k interakci s jinými službami Azure. Klienty ze sady Azure SDK pro .NET můžete vložit pomocí balíčku Microsoft.Extensions.Azure . Po instalaci balíčku zaregistrujte klienty voláním AddAzureClients() kolekce služby v Program.cs. Následující příklad nakonfiguruje pojmenovaného klienta pro objekty blob Azure:

using Microsoft.Extensions.Azure;
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();

Následující příklad ukazuje, jak můžeme pomocí této registrace a typů sady SDK zkopírovat obsah objektů blob jako datový proud z jednoho kontejneru do druhého pomocí injektovaného klienta:

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

    }
}

V ILogger<T> tomto příkladu se také získal prostřednictvím injektáže závislostí, takže se automaticky zaregistruje. Další informace o možnostech konfigurace pro protokolování najdete v tématu Protokolování.

Tip

Příklad použil literálový řetězec pro název klienta v obou Program.cs i funkci. Zvažte místo toho použití sdíleného konstantního řetězce definovaného ve třídě funkce. Můžete například přidat public const string CopyStorageClientName = nameof(_copyContainerClient); a pak odkazovat BlobCopier.CopyStorageClientName na obě umístění. Podobným způsobem můžete definovat název oddílu konfigurace s funkcí místo v Program.cs.

Middleware

Izolované rozhraní .NET také podporuje registraci middlewaru, a to znovu pomocí modelu podobného tomu, co existuje v ASP.NET. Tento model umožňuje vložit logiku do kanálu vyvolání a před a po spuštění funkcí.

ConfigureFunctionsWorkerDefaults extension metoda má přetížení, které umožňuje zaregistrovat vlastní middleware, jak je vidět v následujícím příkladu.

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

Metodu UseWhen rozšíření lze použít k registraci middlewaru, který se spustí podmíněně. Této metodě je nutné předat predikát, který vrátí logickou hodnotu, a middleware se účastní volání kanálu zpracování, pokud je truenávratová hodnota predikátu .

Následující metody rozšíření na FunctionContext usnadňují práci s middlewarem v izolovaném modelu.

metoda	Popis
`GetHttpRequestDataAsync`	`HttpRequestData` Získá instanci při zavolání triggerem HTTP. Tato metoda vrátí instanci `ValueTask<HttpRequestData?>`, která je užitečná, když chcete číst data zpráv, jako jsou hlavičky požadavku a soubory cookie.
`GetHttpResponseData`	`HttpResponseData` Získá instanci při zavolání triggerem HTTP.
`GetInvocationResult`	Získá instanci `InvocationResult`, která představuje výsledek aktuálního spuštění funkce. `Value` Pomocí vlastnosti získejte nebo nastavte hodnotu podle potřeby.
`GetOutputBindings`	Získá výstupní vazby položky pro aktuální spuštění funkce. Každá položka v výsledku této metody je typu `OutputBindingData`. Vlastnost můžete použít `Value` k získání nebo nastavení hodnoty podle potřeby.
`BindInputAsync`	Vytvoří vazbu vstupní položky vazby pro požadovanou `BindingMetadata` instanci. Tuto metodu můžete použít například v případě, že máte funkci se vstupní vazbou `BlobInput` , kterou potřebuje váš middleware použít.

Toto je příklad implementace middlewaru, která čte HttpRequestData instanci a aktualizuje HttpResponseData instanci během provádění funkce:

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

Tento middleware zkontroluje přítomnost konkrétní hlavičky požadavku (x-correlationId) a když je k označení hlavičky odpovědi použitá hodnota hlavičky. V opačném případě vygeneruje novou hodnotu GUID a použije ji pro razítko hlavičky odpovědi. Kompletní příklad použití vlastního middlewaru v aplikaci funkcí najdete v ukázce vlastních referenčních informací k middlewaru.

Přizpůsobení serializace JSON

Model izolovaného pracovního procesu používá System.Text.Json ve výchozím nastavení. Chování serializátoru můžete přizpůsobit konfigurací služeb v rámci souboru Program.cs . Následující příklad ukazuje použití ConfigureFunctionsWebApplication, ale bude fungovat také pro ConfigureFunctionsWorkerDefaults:

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

Místo toho můžete k serializaci použít JSON.NET (Newtonsoft.Json). Uděláte to tak, že balíček nainstalujete Microsoft.Azure.Core.NewtonsoftJson . Potom v registraci služby byste vlastnost WorkerOptions při konfiguraci znovu přiřadiliSerializer. Následující příklad ukazuje použití ConfigureFunctionsWebApplication, ale bude fungovat také pro ConfigureFunctionsWorkerDefaults:

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

Metody rozpoznané jako funkce

Metoda funkce je veřejná metoda veřejné třídy s atributem Function použitým na metodu a atribut trigger použitý na vstupní parametr, jak je znázorněno v následujícím příkladu:

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

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

Atribut Function 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#. Metoda musí být veřejným členem veřejné třídy. Obecně by to měla být metoda instance, aby služby mohly být předány prostřednictvím injektáže závislostí.

Parametry funkce

Tady jsou některé parametry, které můžete zahrnout jako součást podpisu metody funkce:

Vazby, které jsou označené jako takové dekorací parametrů jako atributy. Funkce musí obsahovat přesně jeden parametr triggeru.
Objekt kontextu spuštění, který poskytuje informace o aktuálním vyvolání.
Token zrušení, který se používá k řádnému vypnutí.

Kontext spuštění

Izolované rozhraní .NET předá objekt FunctionContext vašim metodám funkce. Tento objekt umožňuje získat ILogger instanci pro zápis do protokolů voláním GetLogger metody a zadáním categoryName řetězce. Tento kontext můžete použít k získání ILogger bez nutnosti použití injektáže závislostí. Další informace najdete v tématu Protokolování.

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.

Tokeny zrušení jsou podporovány ve funkcích .NET při spuštění v izolovaném pracovním procesu. Následující příklad vyvolá výjimku při přijetí požadavku na zrušení:

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

Následující příklad provádí akce vyčištění při přijetí žádosti o zrušení:

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

Vazby

Vazby jsou definovány pomocí atributů pro metody, parametry a návratové typy. Vazby můžou poskytovat data jako řetězce, pole a serializovatelné typy, jako jsou objekty prosté staré třídy (POCOs). U některých rozšíření vazeb můžete také vytvořit vazbu na typy specifické pro službu definované v sadách SDK služby.

Informace o triggerech HTTP najdete v části triggeru HTTP.

Kompletní sadu referenčních ukázek s využitím triggerů a vazeb s funkcemi izolovaného pracovního procesu najdete v ukázce odkazů na rozšíření vazeb.

Vstupní vazby

Funkce může mít nulové nebo více vstupních vazeb, které mohou předávat data do funkce. Podobně jako triggery jsou vstupní vazby definovány použitím atributu vazby na vstupní parametr. Při spuštění funkce se modul runtime pokusí získat data zadaná v vazbě. Požadovaná data často závisí na informacích poskytovaných triggerem pomocí parametrů vazby.

Výstupní vazby

Pokud chcete zapisovat do výstupní vazby, musíte použít atribut výstupní vazby na metodu funkce, která definuje, jak zapisovat do vázané služby. Hodnota vrácená metodou je zapsána do výstupní vazby. Následující příklad například zapíše řetězcovou hodnotu do fronty zpráv pojmenované output-queue pomocí výstupní vazby:

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

Více výstupních vazeb

Data zapsaná do výstupní vazby jsou vždy návratovou hodnotou funkce. Pokud potřebujete zapisovat do více než jedné výstupní vazby, musíte vytvořit vlastní návratový typ. Tento návratový typ musí mít atribut výstupní vazby použitý na jednu nebo více vlastností třídy. Následující příklad z triggeru HTTP zapisuje do odpovědi HTTP i výstupní vazby fronty:

public static class MultiOutput
{
    [Function(nameof(MultiOutput))]
    public static MyOutputType Run([HttpTrigger(AuthorizationLevel.Anonymous, "get")] HttpRequestData req,
        FunctionContext context)
    {
        var response = req.CreateResponse(HttpStatusCode.OK);
        response.WriteString("Success!");

        string myQueueOutput = "some output";

        return new MyOutputType()
        {
            Name = myQueueOutput,
            HttpResponse = response
        };
    }
}

public class MyOutputType
{
    [QueueOutput("myQueue")]
    public string Name { get; set; }

    public HttpResponseData HttpResponse { get; set; }
}

Odpověď z triggeru HTTP se vždy považuje za výstup, takže atribut návratové hodnoty není povinný.

Typy sad SDK

U některých typů vazeb specifických pro službu je možné data vazby poskytnout pomocí typů ze sad SDK a architektur služby. Poskytují další možnosti nad rámec toho, co serializovaný řetězec nebo prostý objekt CLR (POCO) může nabídnout. Pokud chcete použít novější typy, je potřeba projekt aktualizovat, aby používal novější verze základních závislostí.

Dependency	Požadavek na verzi
Microsoft.Azure.Functions.Worker	1.18.0 nebo novější
Microsoft.Azure.Functions.Worker.Sdk	1.13.0 nebo novější

Při místním testování typů sad SDK na vašem počítači musíte také použít Nástroje Azure Functions Core Tools verze 4.0.5000 nebo novější. Aktuální verzi můžete zkontrolovat pomocí func version příkazu.

Každé rozšíření triggeru a vazby má také vlastní požadavek na minimální verzi, který je popsán v referenčních článcích o rozšíření. Následující vazby specifické pro službu poskytují typy sad SDK:

Služba	Trigger	Vstupní vazba	Výstupní vazba
Objekty blob Azure	Obecně dostupné	Obecně dostupné	Nedoporučují se typy sad SDK.¹
Fronty Azure	Obecně dostupné	Vstupní vazba neexistuje.	Nedoporučují se typy sad SDK.¹
Azure Service Bus	Obecně dostupné	Vstupní vazba neexistuje.	Nedoporučují se typy sad SDK.¹
Azure Event Hubs	Obecně dostupné	Vstupní vazba neexistuje.	Nedoporučují se typy sad SDK.¹
Azure Cosmos DB	Typy sad SDK se nepoužívají²	Obecně dostupné	Nedoporučují se typy sad SDK.¹
Tabulky Azure	Aktivační událost neexistuje.	Obecně dostupné	Nedoporučují se typy sad SDK.¹
Azure Event Grid	Obecně dostupné	Vstupní vazba neexistuje.	Nedoporučují se typy sad SDK.¹

¹ Pro výstupní scénáře, ve kterých byste použili typ sady SDK, byste měli vytvořit a pracovat s klienty sady SDK přímo místo použití výstupní vazby. Příklad injektáže závislostí najdete v tématu Registrace klientů Azure.

² Trigger služby Cosmos DB používá kanál změn služby Azure Cosmos DB a zveřejňuje položky kanálu změn jako serializovatelné typy JSON. Pro tento scénář není k dispozici typy sad SDK.

Poznámka:

Pokud používáte vazbové výrazy, které spoléhají na data triggeru , nelze použít typy sad SDK pro samotný trigger.

Trigger HTTP

Triggery HTTP umožňují vyvolání funkce požadavkem HTTP. Existují dva různé přístupy, které je možné použít:

Model integrace ASP.NET Core, který používá koncepty známé pro vývojáře ASP.NET Core
Integrovaný model, který nevyžaduje další závislosti a používá vlastní typy pro požadavky a odpovědi HTTP. Tento přístup se udržuje kvůli zpětné kompatibilitě s předchozími izolovanými pracovními aplikacemi .NET.

integrace ASP.NET Core

Tato část ukazuje, jak pracovat s podkladovými objekty požadavků HTTP a odpovědí pomocí typů z ASP.NET Core, včetně HttpRequest, HttpResponse a IActionResult. Tento model není k dispozici pro aplikace cílené na rozhraní .NET Framework, které by místo toho měly používat integrovaný model.

Poznámka:

V tomto modelu nejsou vystaveny všechny funkce ASP.NET Core. Konkrétně nejsou k dispozici možnosti ASP.NET základního middlewaru a směrování. integrace ASP.NET Core vyžaduje použití aktualizovaných balíčků.

Povolení integrace ASP.NET Core pro PROTOKOL HTTP:

Přidejte do projektu odkaz na balíček Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore verze 1.0.0 nebo novější.
Aktualizujte projekt tak, aby používal tyto konkrétní verze balíčků:
- Microsoft.Azure.Functions.Worker.Sdk verze 1.11.0. nebo novější
- Microsoft.Azure.Functions.Worker verze 1.16.0 nebo novější.
V souboru aktualizujte Program.cs konfiguraci tvůrce hostitelů tak, aby se používala ConfigureFunctionsWebApplication() místo ConfigureFunctionsWorkerDefaults(). Následující příklad ukazuje minimální nastavení bez dalších přizpůsobení:
```
using Microsoft.Extensions.Hosting;
using Microsoft.Azure.Functions.Worker;

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

host.Run();
```
Aktualizujte všechny existující funkce aktivované protokolem HTTP tak, aby používaly typy ASP.NET Core. Tento příklad ukazuje standard HttpRequest a IActionResult používá se pro jednoduchou funkci "hello, world":
```
[Function("HttpFunction")]
public IActionResult Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get")] HttpRequest req)
{
    return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
}
```

Integrovaný model HTTP

V integrovaném modelu systém přeloží příchozí zprávu požadavku HTTP na objekt HttpRequestData , který je předán funkci. Tento objekt poskytuje data z požadavku, včetně Headers, Cookies, Identities, URLa volitelně zprávy Body. Tento objekt představuje požadavek HTTP, ale není přímo připojený k podkladovému naslouchacímu procesu HTTP nebo přijaté zprávě.

Podobně funkce vrátí objekt HttpResponseData , který poskytuje data použitá k vytvoření odpovědi HTTP, včetně zprávy StatusCode, Headersa volitelně zprávy Body.

Následující příklad ukazuje použití HttpRequestData a HttpResponseData:

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

Protokolování

V izolovaném prostředí .NET můžete zapisovat do protokolů pomocí instance ILogger<T> nebo ILogger instance. Protokolovací objekt lze získat prostřednictvím injektáže ILogger<T> závislostí nebo ILoggerFactory:

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

}

Protokolovací objekt lze také získat z objektu FunctionContext předaného vaší funkci. Volání GetLogger<T> nebo GetLogger metoda, která předává řetězcovou hodnotu, která je název kategorie, ve které jsou protokoly zapsány. Kategorie je obvykle název konkrétní funkce, ze které se protokoly zapisují. Další informace o kategoriích najdete v článku o monitorování.

Použití metod ILogger<T> a ILogger zápisu různých úrovní protokolu, například LogWarning nebo LogError. Další informace o úrovních protokolů najdete v článku o monitorování. Úrovně protokolů pro komponenty přidané do kódu můžete přizpůsobit registrací filtrů v rámci HostBuilder konfigurace:

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

V rámci konfigurace aplikace můžete Program.cstaké definovat chování způsobu, jakým se chyby zobrazují v protokolech. Ve výchozím nastavení můžou výjimky vyvolané vaším kódem skončit zabalené do souboru RpcException. Pokud chcete tuto extra vrstvu EnableUserCodeException odebrat, nastavte vlastnost na true jako součást konfigurace tvůrce:

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

Application Insights

Aplikaci izolovaného procesu můžete nakonfigurovat tak, aby vygenerovala protokoly přímo do aplikace Přehledy. Toto chování nahrazuje výchozí chování předávání protokolů prostřednictvím hostitele a doporučuje se, protože vám dává kontrolu nad tím, jak se tyto protokoly vygenerují.

Instalace balíčků

Pokud chcete zapisovat protokoly přímo do aplikace Přehledy z kódu, přidejte do projektu odkazy na tyto balíčky:

Microsoft.Azure.Functions.Worker.Application Přehledy verze 1.0.0 nebo novější.
Microsoft.Application Přehledy. WorkerService.

Spuštěním následujících příkazů můžete do projektu přidat tyto odkazy:

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

Konfigurace spuštění

S nainstalovanými balíčky musíte volat AddApplicationInsightsTelemetryWorkerService() a ConfigureFunctionsApplicationInsights() během konfigurace služby v Program.cs souboru, jak je znázorněno v tomto příkladu:

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

Volání, které ConfigureFunctionsApplicationInsights() přidá , ITelemetryModulekterý naslouchá funkcím definovaný ActivitySource. Tím se vytvoří telemetrie závislostí potřebná k podpoře distribuovaného trasování. Další informace o AddApplicationInsightsTelemetryWorkerService() aplikaci a o tom, jak ji používat, najdete v tématu Přehledy aplikace pracovních služeb.

Správa úrovní protokolů

Důležité

Hostitel služby Functions a pracovní proces izolovaného procesu mají samostatnou konfiguraci pro úrovně protokolů atd. Jakákoli konfigurace aplikace Přehledy v host.json nebude mít vliv na protokolování od pracovního procesu a podobně nebude mít konfigurace provedená v kódu pracovního procesu vliv na protokolování z hostitele. Pokud váš scénář vyžaduje přizpůsobení v obou vrstvách, musíte změny použít na obou místech.

Zbývající část aplikace nadále pracuje s ILogger aplikací a ILogger<T>. Sada Application Insights SDK ale ve výchozím nastavení přidává filtr protokolování, který protokolovacímu nástroji dává pokyn, aby zaznamenával pouze upozornění a vážnější protokoly. Pokud chcete toto chování zakázat, odeberte pravidlo filtru jako součást konfigurace služby:

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

Optimalizace výkonu

Tato část popisuje možnosti, které umožňují zvýšit výkon při studeném startu.

Obecně platí, že vaše aplikace by měla používat nejnovější verze základních závislostí. Projekt byste měli minimálně aktualizovat následujícím způsobem:

Upgradujte Microsoft.Azure.Functions.Worker na verzi 1.19.0 nebo novější.
Upgradujte Microsoft.Azure.Functions.Worker.Sdk na verzi 1.16.4 nebo novější.
Pokud vaše aplikace cílí na rozhraní .NET Framework, přidejte odkaz na Microsoft.AspNetCore.Apparchitekturu.

Následující fragment kódu ukazuje tuto konfiguraci v kontextu souboru projektu:

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

Zástupné symboly

Zástupné symboly jsou funkce platformy, která zlepšuje studený start pro aplikace, které cílí na .NET 6 nebo novější. Pokud chcete tuto optimalizaci použít, musíte zástupné symboly explicitně povolit pomocí následujícího postupu:

Aktualizujte konfiguraci projektu tak, aby používala nejnovější verze závislostí, jak je podrobně popsáno v předchozí části.
WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED Nastavte nastavení aplikace na 1, které můžete provést pomocí tohoto příkazu az functionapp config appsettings set:
```
az functionapp config appsettings set -g <groupName> -n <appName> --settings 'WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED=1'
```
V tomto příkladu nahraďte <groupName> názvem skupiny prostředků a nahraďte <appName> názvem vaší aplikace funkcí.
Ujistěte se, že netFrameworkVersion vlastnost aplikace funkcí odpovídá cílové rozhraní vašeho projektu, což musí být .NET 6 nebo novější. Můžete to provést pomocí tohoto příkazu az functionapp config set :
```
az functionapp config set -g <groupName> -n <appName> --net-framework-version <framework>
```
V tomto příkladu nahraďte <framework> také odpovídajícím řetězcem verze, například v8.0, v7.0nebo v6.0, podle vaší cílové verze .NET.
Ujistěte se, že je vaše aplikace funkcí nakonfigurovaná tak, aby používala 64bitový proces, který můžete provést pomocí tohoto příkazu az functionapp config set :
```
az functionapp config set -g <groupName> -n <appName> --use-32bit-worker-process false
```

Důležité

Při nastavování WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED na 1hodnotu musí být správně nastaveny všechny ostatní konfigurace aplikace funkcí. Jinak se aplikace funkcí nemusí spustit.

Optimalizovaný exekutor

Exekutor funkce je komponenta platformy, která způsobuje spuštění vyvolání. Optimalizovaná verze této komponenty je ve výchozím nastavení povolená od verze 1.16.2 sady SDK. Nevyžaduje se žádná jiná konfigurace.

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í, což pomáhá snížit účinek studených startů 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 nebo novější modulu runtime Azure Functions.

ReadyToRun vyžaduje, abyste projekt sestavili v architektuře modulu runtime hostitelské aplikace. Pokud tyto hodnoty nejsou zarovnané, aplikace při spuštění narazí na chybu. V této tabulce vyberte identifikátor modulu runtime:

Operační systém	Aplikace je 32bitová 1.	Identifikátor modulu runtime
Windows	True	`win-x86`
Windows	False	`win-x64`
Linux	True	Není k dispozici (nepodporuje se)
Linux	False	`linux-x64`

¹ Pouze 64bitové aplikace mají nárok na některé další optimalizace výkonu.

Pokud chcete zkontrolovat, jestli je vaše aplikace pro Windows 32bitová nebo 64bitová, můžete spustit následující příkaz rozhraní příkazového řádku, nahradit <group_name> názvem vaší skupiny prostředků a <app_name> názvem vaší aplikace. Výstup "true" označuje, že aplikace je 32bitová a "false" označuje 64bitovou verzi.

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

Aplikaci můžete změnit na 64bitovou verzi pomocí následujícího příkazu, a to pomocí stejných nahrazení:

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

Pokud chcete projekt zkompilovat jako ReadyToRun, aktualizujte soubor projektu přidáním <PublishReadyToRun> prvků a <RuntimeIdentifier> prvků. Následující příklad ukazuje konfiguraci pro publikování do 64bitové aplikace funkcí pro Windows.

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

Pokud nechcete nastavit <RuntimeIdentifier> soubor projektu jako součást souboru projektu, můžete ho také nakonfigurovat jako součást samotného gesta publikování. Například s 64bitovou aplikací funkcí pro Windows by příkaz .NET CLI byl:

dotnet publish --runtime win-x64

V sadě Visual Studio by měla být možnost Cílový modul runtime v profilu publikování nastavená na správný identifikátor modulu runtime. Pokud je nastavena výchozí hodnota Portable, ReadyToRun se nepoužívá.

Nasazení do Azure Functions

Když nasadíte projekt kódu funkce do Azure, musí se spustit buď v aplikaci funkcí, nebo v kontejneru Linuxu. Aplikace funkcí a další požadované prostředky Azure musí existovat před nasazením kódu.

Aplikaci funkcí můžete také nasadit v kontejneru Linuxu. Další informace najdete v tématu Práce s kontejnery a Azure Functions.

Vytvoření zdrojů Azure

Aplikaci funkcí a další požadované prostředky v Azure můžete vytvořit pomocí jedné z těchto metod:

Visual Studio: Visual Studio pro vás může během procesu publikování kódu vytvářet prostředky.
Visual Studio Code: Visual Studio Code se může připojit k vašemu předplatnému, vytvořit prostředky potřebné vaší aplikací a pak publikovat kód.
Azure CLI: K vytvoření požadovaných prostředků v Azure můžete použít Azure CLI.
Azure PowerShell: K vytvoření požadovaných prostředků v Azure můžete použít Azure PowerShell.
Šablony nasazení: K automatizaci nasazení požadovaných prostředků do Azure můžete použít šablony ARM a soubory Bicep. Ujistěte se, že vaše šablona obsahuje všechna požadovaná nastavení.
Azure Portal: Požadované prostředky můžete vytvořit na webu Azure Portal.

Publikování projektu kódu

Po vytvoření aplikace funkcí a dalších požadovaných prostředků v Azure můžete projekt kódu nasadit do Azure pomocí jedné z těchto metod:

Visual Studio: Jednoduché ruční nasazení během vývoje
Visual Studio Code: Jednoduché ruční nasazení během vývoje
Azure Functions Core Tools: Nasaďte soubor projektu z příkazového řádku.
Průběžné nasazování: Užitečné pro průběžnou údržbu, často do přípravného slotu.
Šablony nasazení: K automatizaci nasazení balíčků můžete použít šablony ARM nebo soubory Bicep.

Další informace najdete v tématu Technologie nasazení ve službě Azure Functions.

Požadavky na nasazení

V závislosti na operačním systému existuje několik požadavků na spouštění funkcí .NET v izolovaném pracovním modelu v Azure:

Windows
Linux

FUNCTIONS_WORKER_RUNTIME musí být nastavena na hodnotu dotnet-isolated.
NetFrameworkVersion musí být nastavena na požadovanou verzi.

Při vytváření aplikace funkcí v Azure pomocí metod v předchozí části se tato požadovaná nastavení přidají za vás. Při vytváření těchto prostředků pomocí šablon ARM nebo souborů Bicep pro automatizaci je nutné je nastavit v šabloně.

Ladění

Při místním spuštění pomocí sady Visual Studio nebo Editoru Visual Studio Code můžete ladit projekt izolovaného pracovního procesu .NET jako obvykle. Existují však dva scénáře ladění, které nefungují podle očekávání.

Vzdálené ladění pomocí sady Visual Studio

Vzhledem k tomu, že aplikace izolovaného pracovního procesu běží mimo modul runtime Služby Functions, musíte vzdálený ladicí program připojit k samostatnému procesu. Další informace o ladění pomocí sady Visual Studio najdete v tématu Vzdálené ladění.

Ladění při cílení na rozhraní .NET Framework

Pokud váš izolovaný projekt cílí na rozhraní .NET Framework 4.8, aktuální obor preview vyžaduje ruční kroky pro povolení ladění. Pokud používáte jinou cílovou architekturu, tyto kroky se nevyžadují.

Aplikace by měla začínat voláním FunctionsDebugger.Enable(); jako první operace. K tomu dochází v Main() metodě před inicializací HostBuilder. Soubor Program.cs by měl vypadat nějak takto:

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

Dále je potřeba ručně připojit k procesu pomocí ladicího programu rozhraní .NET Framework. Visual Studio to zatím neprovádí automaticky pro aplikace .NET Framework izolovaného pracovního procesu a operace Spustit ladění by se měla vyhnout.

V adresáři projektu (nebo jeho výstupním adresáři sestavení) spusťte:

func host start --dotnet-isolated-debug

Tím se spustí váš pracovní proces a proces se zastaví následující zprávou:

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

Kde <process id> je ID pracovního procesu. K ručnímu připojení k procesu teď můžete použít Visual Studio. Pokyny k této operaci najdete v tématu Připojení ke spuštěném procesu.

Po připojení ladicího programu se provádění procesu obnoví a budete moct ladit.

Verze Preview .NET

Před obecně dostupnou verzí může být verze .NET vydána ve stavu Preview nebo Go Live . Podrobnosti o těchto státech najdete v oficiálních zásadách podpory .NET.

I když může být možné cílit na danou verzi z místního projektu Functions, aplikace funkcí hostované v Azure nemusí mít k dispozici danou verzi. Azure Functions se dají používat jenom s verzemi Preview nebo VerzeMi v reálném provozu, které jsou uvedené v této části.

Azure Functions v současné době nefunguje s žádnými verzemi .NET ve verzi Preview nebo Go-live. Seznam obecně dostupných verzí, které můžete použít, najdete v části Podporované verze .

Použití sady .NET SDK ve verzi Preview

Pokud chcete používat Azure Functions s verzí Preview .NET, musíte projekt aktualizovat pomocí těchto možností:

Instalace příslušné verze sady .NET SDK ve vašem vývoji
TargetFramework Změna nastavení v .csproj souboru

Při nasazování do aplikace funkcí v Azure musíte také zajistit, aby byla architektura dostupná pro danou aplikaci. K tomu ve Windows můžete použít následující příkaz rozhraní příkazového řádku. Nahraďte <groupName> názvem skupiny prostředků a nahraďte <appName> názvem vaší aplikace funkcí. Nahraďte <framework> odpovídajícím řetězcem verze, například v8.0.

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

Důležité informace o používání verzí .NET Preview

Při používání funkcí s verzemi Preview .NET mějte na paměti tyto aspekty:

Při vytváření funkcí v sadě Visual Studio musíte použít Sadu Visual Studio Preview, která podporuje vytváření projektů Azure Functions pomocí sad SDK .NET Preview.
Ujistěte se, že máte nejnovější nástroje a šablony Functions. Aktualizace nástrojů:
1. Přejděte na Možnosti nástrojů>a v části Projekty a řešení zvolte Azure Functions.
2. Podle výzvy vyberte Vyhledat aktualizace a nainstalovat aktualizace.
Během období Preview může mít vaše vývojové prostředí novější verzi .NET Preview než hostovaná služba. To může způsobit selhání vaší aplikace funkcí při nasazení. Chcete-li to vyřešit, můžete zadat verzi sady SDK, ve global.jsonkteré se má použít .
1. dotnet --list-sdks Spusťte příkaz a poznamenejte si verzi Preview, kterou aktuálně používáte při místním vývoji.
2. dotnet new globaljson --sdk-version <SDK_VERSION> --force Spusťte příkaz, kde <SDK_VERSION> je verze, kterou používáte místně. Například způsobí, dotnet new globaljson --sdk-version dotnet-sdk-8.0.100-preview.7.23376.3 --force že systém při sestavování projektu použije sadu .NET 8 Preview 7 SDK.

Poznámka:

Vzhledem k načítání architektur preview za běhu můžou aplikace funkcí běžící ve Windows při porovnání se staršími verzemi GA zaznamenat vyšší dobu spuštění za běhu.

Další kroky

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

Migrace aplikací .NET do izolovaného pracovního modelu

Průvodce spuštěním azure Functions v C# v izolovaném pracovním modelu

Výhody izolovaného modelu pracovního procesu

Podporované verze

Struktura projektu

Odkazy na balíčky

Základní balíčky

Balíčky rozšíření

Spuštění a konfigurace

Konfigurace

Injektáž závislostí

Registrace klientů Azure

Middleware

Přizpůsobení serializace JSON

Metody rozpoznané jako funkce

Parametry funkce

Kontext spuštění

Tokeny zrušení

Vazby

Vstupní vazby

Výstupní vazby

Více výstupních vazeb

Typy sad SDK

Trigger HTTP

integrace ASP.NET Core

Integrovaný model HTTP

Protokolování

Application Insights

Instalace balíčků

Konfigurace spuštění

Správa úrovní protokolů

Optimalizace výkonu

Zástupné symboly

Optimalizovaný exekutor

ReadyToRun

Nasazení do Azure Functions

Vytvoření zdrojů Azure

Publikování projektu kódu

Požadavky na nasazení

Ladění

Vzdálené ladění pomocí sady Visual Studio

Ladění při cílení na rozhraní .NET Framework

Verze Preview .NET

Použití sady .NET SDK ve verzi Preview

Důležité informace o používání verzí .NET Preview

Další kroky

Další materiály