使用 Azure Functions 開發 C# 類別庫函式

本文是在 .NET 類別庫中使用 C# 開發 Azure Functions 的簡介。

重要事項

本文支援使用執行階段來同處理序執行的 .NET 類別庫函式。 您的 C# 函式也可以在處理程序外執行,並與 Functions 執行階段隔離。 隔離的模型是使用最新版 Functions 執行階段執行 .NET 5.x 與 .NET Framework 4.8 預覽的唯一方式。 若要深入了解,請參閱 .NET 隔離式處理序函式

身為 C# 開發人員,您可能也對下列其中一篇文章感興趣:

開始使用 概念 引導式學習/範例

Azure Functions 支援 C# 和 C# 指令碼程式設計語言。 如果您需要在 Azure 入口網站中使用 C#的指引,請參閱 C# 指令碼 (.csx) 開發人員參考

支援的版本

Functions 執行階段的版本適用於 .NET 特定版本。 若要深入了解 Functions 版本,請參閱 Azure Functions 執行階段版本概觀。 版本支援取決於函式是否為同處理序執行或在處理程序外 (已隔離) 執行。

注意

若要了解如何變更函數應用程式所使用的 Functions 執行階段版本,請參閱檢視及更新目前的執行階段版本

下表顯示可與 Functions 特定版本搭配使用的最高層級 .NET Core 或 .NET Framework。

Functions 執行階段版本 內含式
(.NET 類別庫)
跨處理序
(.NET 已隔離)
Functions 4.x .NET 6.0 .NET 6.0
.NET 7.0 (預覽)
.NET Framework 4.8 (預覽)1
Functions 3.x .NET Core 3.1 .NET 5.02
Functions 2.x .NET Core 2.13 n/a
Functions 1.x .NET Framework 4.8 n/a

1 建置處理序也需要 .NET 6 SDK。 .NET Framework 4.8 的支援處於預覽狀態。

2 建置處理序也需要 .NET Core 3.1 SDK

3 如需詳細資料,請參閱 Functions v2.x 考量

如需有關 Azure Functions 版本的最新新聞,包括移除特定舊版次要版本,請持續關注 Azure App Service 公告

Functions v2.x 考量

以最新的 2.x 版 (~2) 為目標的函數應用程式會自動升級為在 .NET Core 3.1 上執行。 因為 .NET Core 版本之間的重大變更,所以並非所有針對 .NET Core 2.2 開發及編譯的應用程式都可以安全地升級至 .NET Core 3.1。 您可以將函數應用程式釘選至 ~2.0 以退出此升級。 Functions 也會偵測不相容的 API 並可能會將您的應用程式釘選至 ~2.0,以避免 .NET Core 3.1 上的不正確執行。

注意

若已將您的函數應用程式釘選至 ~2.0,並將此版本目標變更為 ~2,則您的函數應用程式可能會中斷。 若您使用 ARM 範本進行部署,請檢查範本中的版本。 若發生此情況,請將您的版本變更回目標 ~2.0 並修正相容性問題。

~2.0 為目標的函數應用程式會繼續在 .NET Core 2.2 上執行。 此版本的 .NET Core 不會再收到安全性與其他維護更新。 若要深入了解,請參閱此公告頁面

您應該儘快讓您的函式與 .NET Core 3.1 相容。 解決這些問題之後,請將版本變更回 ~2 或升級至 ~3。 若要深入了解 Functions 執行階段的目標版本,請參閱如何以 Azure Functions 執行階段版本為目標

在進階或專用 (App Service) 方案中的 Linux 上執行時,您可以藉由將 linuxFxVersion 網站組態設定設定為 DOCKER|mcr.microsoft.com/azure-functions/dotnet:2.0.14786-appservice (而不是以特定映像為目標) 來釘選版本。若要了解如何設定 linuxFxVersion,請參閱 Linux 上的手動版本更新

Functions 類別庫專案

在 Visual Studio 中,Azure Functions 專案範本可建立 C# 類別庫專案,其中包含下列檔案:

當您建置專案時,組建輸出目錄中會產生類似下列範例的資料夾結構:

<framework.version>
 | - bin
 | - MyFirstFunction
 | | - function.json
 | - MySecondFunction
 | | - function.json
 | - host.json

此目錄會部署至 Azure 中的函數應用程式。 Functions 執行階段版本 2.x 中所需之繫結延伸模組會以 NuGet 封裝形式新增至專案

重要事項

建置流程會為每個函式都建立 function.json 檔案。 這個 function.json 檔案不適合直接編輯。 您無法編輯此檔案來變更繫結設定或停用函式。 若要了解如何停用函式,請參閱如何停用函式

辨識為函式的方法

在類別庫中,函式是具有 FunctionName 和觸發程序屬性的靜態方法,如下列範例所示:

public static class SimpleExample
{
    [FunctionName("QueueTrigger")]
    public static void Run(
        [QueueTrigger("myqueue-items")] string myQueueItem, 
        ILogger log)
    {
        log.LogInformation($"C# function processed: {myQueueItem}");
    }
} 

FunctionName 屬性會將方法標記為函式進入點。 名稱在專案中不可重複,必須以字母開頭,且只能包含字母、數字、_-,長度不可超過 127 個字元。 專案範本通常會建立名為 Run 的方法,不過任何有效的 C# 方法名稱都能成為方法名稱。

觸發程序屬性可指定觸發程序類型,並將輸入資料繫結至方法參數。 範例函式是由佇列訊息所觸發,該佇列訊息會接著傳遞給 myQueueItem 參數中的方法。

方法簽章參數

方法簽章可包含非用於觸發程序屬性的參數。 以下是幾個可以包含在其中的其他參數:

函式簽章中的參數順序不重要。 例如,您可以將觸發程序參數放在其他繫結之前或之後,且可以將記錄器參數放在觸發程序或繫結參數之前或之後。

輸出繫結

函式可以使用輸出參數來定義零或一個輸出繫結。

下列範例藉由新增名為 myQueueItemCopy 的輸出佇列繫結來修改上一個範例。 此函式會將觸發函式的訊息內容寫入不同佇列中的新訊息。

public static class SimpleExampleWithOutput
{
    [FunctionName("CopyQueueMessage")]
    public static void Run(
        [QueueTrigger("myqueue-items-source")] string myQueueItem, 
        [Queue("myqueue-items-destination")] out string myQueueItemCopy,
        ILogger log)
    {
        log.LogInformation($"CopyQueueMessage function processed: {myQueueItem}");
        myQueueItemCopy = myQueueItem;
    }
}

指派給輸出繫結的值會在函式結束時寫入。 只要將值指派給多個輸出參數,即可在函式中使用多個輸出繫結。

繫結參考文章 (如儲存體佇列) 說明您可以使用哪些類型的參數來搭配觸發程序、輸入或輸出繫結屬性。

繫結運算式範例

下列程式碼會從應用程式設定取得要監視的佇列名稱,而它會在 insertionTime 參數中取得佇列訊息建立時間。

public static class BindingExpressionsExample
{
    [FunctionName("LogQueueMessage")]
    public static void Run(
        [QueueTrigger("%queueappsetting%")] string myQueueItem,
        DateTimeOffset insertionTime,
        ILogger log)
    {
        log.LogInformation($"Message content: {myQueueItem}");
        log.LogInformation($"Created at: {insertionTime}");
    }
}

自動產生的 function.json

建置流程在組建資料夾的函式資料夾中建立 function.json 檔案。 如稍早所述,此檔案不適合直接編輯。 您無法編輯此檔案來變更繫結設定或停用函式。

此檔案的用途為提供資訊給調整控制器,以用於使用情況方案的調整決策。 因此,檔案只會有觸發程序資訊,而不會有輸入/輸出繫結。

產生的 function.json 檔案包含 configurationSource 屬性 (property),指示執行階段使用 .NET 屬性 (attribute) 屬性進行繫結,而不是使用 function.json 設定。 以下為範例:

{
  "generatedBy": "Microsoft.NET.Sdk.Functions-1.0.0.0",
  "configurationSource": "attributes",
  "bindings": [
    {
      "type": "queueTrigger",
      "queueName": "%input-queue-name%",
      "name": "myQueueItem"
    }
  ],
  "disabled": false,
  "scriptFile": "..\\bin\\FunctionApp1.dll",
  "entryPoint": "FunctionApp1.QueueTrigger.Run"
}

Microsoft.NET.Sdk.Functions

function.json 檔案產生是由 NuGet 套件 Microsoft.NET.Sdk.Functions 所執行。

Functions 執行階段的 1.x 版和 2.x 版都是使用同一個套件。 1.x 專案與 2.x 專案可依目標架構來區分。 以下是 .csproj 檔案的相關部分,其顯示不同的目標架構與相同的 Sdk 套件:

<PropertyGroup>
  <TargetFramework>netcoreapp2.1</TargetFramework>
  <AzureFunctionsVersion>v2</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.8" />
</ItemGroup>

Sdk 套件相依性中的是觸發程序和繫結。 1.x 專案代表 1.x 觸發程序與繫結,因為這些觸發程序與繫結會將目標設定為 .NET Framework,而 2.x 觸發程序與繫結則會將目標設定為 .NET Core。

Sdk 套件也會相依於 Newtonsoft.Json \(英文\),並間接相依於 WindowsAzure.Storage \(英文\)。 這些相依性可確保您的專案會使用能夠搭配專案所設為目標之 Functions 執行階段版本運作的套件版本。 例如,Newtonsoft.Json 含有適用於 .NET Framework 4.6.1 的 11 版,但目標為 .NET Framework 4.6.1 的 Functions 執行階段只能與 Newtonsoft.Json 9.0.1 相容。 因此,您在該專案中的函式程式碼也必須使用 Newtonsoft.Json 9.0.1。

GitHub 存放庫 azure-functions-vs-build-sdk 中有適用於 Microsoft.NET.Sdk.Functions 的原始程式碼可供使用。

本機執行階段版本

Visual Studio 會使用 Azure Functions Core Tools,在您的本機電腦上執行 Functions 專案。 Core Tools 是適用於 Functions 執行階段的命令列介面。

若您使用 Windows installer (MSI) 套件或 npm 來安裝 Core Tools,就不會影響 Visual Studio 所使用的 Core Tools 版本。 對於 Functions 執行階段 1.x 版,Visual Studio 會在 %USERPROFILE%\AppData\Local\Azure.Functions.Cli 中儲存 Core Tools 版本,並使用儲存於該處的最新版本。 對於 Functions 2.x,Core Tools 會隨附於 Azure Functions 與 Web 工作工具擴充功能中。 對於 1.x 和 2.x,您可以在執行 Functions 專案時,於主控台輸出中查看使用的是哪個版本:

[3/1/2018 9:59:53 AM] Starting Host (HostId=contoso2-1518597420, Version=2.0.11353.0, ProcessId=22020, Debug=False, Attempt=0, FunctionsExtensionVersion=)

ReadyToRun

您可以將函數應用程式編譯為 ReadyToRun 二進位檔。 ReadyToRun 是一種預先編譯形式,可改善啟動效能,以協助降低在使用情況方案中執行時冷啟動的影響。

ReadyToRun 可在 .NET 3.0 中使用,且需要 Azure Functions 執行階段 3.0 版

若要將專案編譯為 ReadyToRun,請新增 <PublishReadyToRun><RuntimeIdentifier> 元素來更新專案檔。 下列是發佈至 Windows 32 位元函數應用程式的設定。

<PropertyGroup>
  <TargetFramework>netcoreapp3.1</TargetFramework>
  <AzureFunctionsVersion>v3</AzureFunctionsVersion>
  <PublishReadyToRun>true</PublishReadyToRun>
  <RuntimeIdentifier>win-x86</RuntimeIdentifier>
</PropertyGroup>

重要事項

ReadyToRun 目前不支援交叉編譯。 您必須在與部署目標相同的平台上建置應用程式。 此外,另請注意在函數應用程式中設定的「位元」。 例如,若您 Azure 中的函數應用程式是 Windows 64 位元,則必須在 Windows 上使用 win-x64 作為執行階段識別碼來編譯應用程式。

您也可以從命令列使用 ReadyToRun 來建置應用程式。 如需詳細資訊,請參閱 dotnet publish 中的 -p:PublishReadyToRun=true 選項。

支援的繫結類型

每個繫結都有自己支援的類型;例如,Blob 觸發程序屬性可套用至字串參數、POCO 參數、CloudBlockBlob 參數或任何數個其他支援的類型。 Blob 繫結的繫結參考文章會列出所有支援的參數類型。 如需詳細資訊,請參閱觸發程序和繫結以及每個繫結類型的繫結參考文件

秘訣

如果您打算使用 HTTP 或 WebHook 的繫結,請做好規劃,以免因為 HttpClient 具現化不當而耗盡連接埠。 如需詳細資訊,請參閱如何管理 Azure Functions 中的連線

繫結至方法傳回值

您可以將方法傳回值用於輸出繫結,方法是將屬性套用至方法傳回值。 如需範例,請參閱觸發程序和繫結

唯有成功的函式執行一律導致傳回值傳遞至輸出繫結時,才使用此傳回值。 否則,使用 ICollectorIAsyncCollector,如下一節所示。

撰寫多個輸出值

若要將多個值寫入至輸出繫結,或者如果成功的函式引動過程可能未導致任何項目傳遞至輸出繫結,請使用 ICollectorIAsyncCollector 類型。 這些類型是在方法完成時,寫入至輸出繫結的唯寫集合。

這個範例會使用 ICollector 將多個佇列訊息寫入相同佇列:

public static class ICollectorExample
{
    [FunctionName("CopyQueueMessageICollector")]
    public static void Run(
        [QueueTrigger("myqueue-items-source-3")] string myQueueItem,
        [Queue("myqueue-items-destination")] ICollector<string> myDestinationQueue,
        ILogger log)
    {
        log.LogInformation($"C# function processed: {myQueueItem}");
        myDestinationQueue.Add($"Copy 1: {myQueueItem}");
        myDestinationQueue.Add($"Copy 2: {myQueueItem}");
    }
}

非同步處理

若要讓函式變成非同步,請使用 async 關鍵字並傳回 Task 物件。

public static class AsyncExample
{
    [FunctionName("BlobCopy")]
    public static async Task RunAsync(
        [BlobTrigger("sample-images/{blobName}")] Stream blobInput,
        [Blob("sample-images-copies/{blobName}", FileAccess.Write)] Stream blobOutput,
        CancellationToken token,
        ILogger log)
    {
        log.LogInformation($"BlobCopy function processed.");
        await blobInput.CopyToAsync(blobOutput, 4096, token);
    }
}

您無法在非同步函式中使用 out 參數。 針對輸出繫結,請改為使用函式傳回值收集器物件

取消權杖

可以接受 CancellationToken 參數的函式,讓作業系統能夠在函式即將終止時通知您的程式碼。 您可以使用此通知來確保函數不會在讓資料維持不一致狀態的情況下意外終止。

請考慮您有函式以批次方式處理訊息的情況。 下列觸發 Azure 服務匯流排的函式會處理 Message 物件的陣列,其代表特定函式叫用所要處理的內送訊息批次:

using Microsoft.Azure.ServiceBus;
using System.Threading;

namespace ServiceBusCancellationToken
{
    public static class servicebus
    {
        [FunctionName("servicebus")]
        public static void Run([ServiceBusTrigger("csharpguitar", Connection = "SB_CONN")]
               Message[] messages, CancellationToken cancellationToken, ILogger log)
        {
            try
            { 
                foreach (var message in messages)
                {
                    if (cancellationToken.IsCancellationRequested)
                    {
                        log.LogInformation("A cancellation token was received. Taking precautionary actions.");
                        //Take precautions like noting how far along you are with processing the batch
                        log.LogInformation("Precautionary activities --complete--.");
                        break;
                    }
                    else
                    {
                        //business logic as usual
                        log.LogInformation($"Message: {message} was processed.");
                    }
                }
            }
            catch (Exception ex)
            {
                log.LogInformation($"Something unexpected happened: {ex.Message}");
            }
        }
    }
}

記錄

您可以在函式程式碼中將輸出寫入記錄,其會在 Application Insights 中顯示為追蹤。 寫入記錄的建議方式是包含 ILogger 類型的參數,其通常命名為 log。 使用 TraceWriter 的 1.x 版 Functions 執行階段也會寫入 Application Insights,但不支援結構化記錄。 請勿使用 Console.Write 來寫入記錄,因為 Application Insights 不會擷取此資料。

ILogger

在您的函式定義中,包含支援結構化記錄ILogger 參數。

利用 ILogger 物件,您可以呼叫 Log<level>擴充方法 (位於 ILogger 上) \(英文\) 來建立記錄。 下列程式碼會寫入 Information 記錄且類別為 Function.<YOUR_FUNCTION_NAME>.User.

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, ILogger logger)
{
    logger.LogInformation("Request for item with key={itemKey}.", id);

若要深入了解 Functions 如何實作 ILogger,請參閱收集遙測資料。 前面加上 Function 的類別假設您使用 ILogger 執行個體。 若您選擇改用 ILogger<T>,則類別名稱可能會改為以 T 為基礎。

結構化記錄

預留位置的順序 (而不是名稱) 會決定要在記錄訊息中使用的參數。 假設您有下列程式碼:

string partitionKey = "partitionKey";
string rowKey = "rowKey";
logger.LogInformation("partitionKey={partitionKey}, rowKey={rowKey}", partitionKey, rowKey);

如果您保留相同的訊息字串並反轉參數的順序,則產生的訊息文字值會處於錯誤的位置上。

您可以使用這種方式來處理預留位置,讓您能夠執行結構化記錄。 Application Insights 會儲存參數名稱/值組和訊息字串。 結果就是訊息引數會變成您可以查詢的欄位。

如果您的記錄器方法呼叫看起來類似上述範例,則您可以查詢 customDimensions.prop__rowKey 欄位。 prop__ 前置詞已新增,以確保執行階段新增的欄位與您函式程式碼新增的欄位之間沒有衝突。

您也可以藉由參考欄位 customDimensions.prop__{OriginalFormat},在原始訊息字串上進行查詢。

以下是 customDimensions 資料的範例 JSON 表示法:

{
  "customDimensions": {
    "prop__{OriginalFormat}":"C# Queue trigger function processed: {message}",
    "Category":"Function",
    "LogLevel":"Information",
    "prop__message":"c9519cbf-b1e6-4b9b-bf24-cb7d10b1bb89"
  }
}

記錄自訂遙測資料

有一個 Functions 特定版本的 Application Insights SDK,可讓您將自訂遙測資料從函式傳送到 Application Insights:Microsoft.Azure.WebJobs.Logging.ApplicationInsights \(英文\)。 從命令提示字元中,使用下列命令來安裝此套件:

dotnet add package Microsoft.Azure.WebJobs.Logging.ApplicationInsights --version <VERSION>

在此命令中,將 <VERSION> 取代為此套件的版本,以支援您已安裝的 Microsoft.Azure.WebJobs \(英文\) 版本。

下列 C# 範例會使用自訂遙測 API。 此範例適用於 .NET 類別庫,但 Application Insights 程式碼同樣適用於 C# 指令碼。

2\.x 版和更新版本的執行階段會使用 Application Insights 中的新功能,自動將遙測與目前作業相互關聯。 不需要手動設定作業 IdParentIdName 欄位。

using System;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;

using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
using System.Linq;

namespace functionapp0915
{
    public class HttpTrigger2
    {
        private readonly TelemetryClient telemetryClient;

        /// Using dependency injection will guarantee that you use the same configuration for telemetry collected automatically and manually.
        public HttpTrigger2(TelemetryConfiguration telemetryConfiguration)
        {
            this.telemetryClient = new TelemetryClient(telemetryConfiguration);
        }

        [FunctionName("HttpTrigger2")]
        public Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = null)]
            HttpRequest req, ExecutionContext context, ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");
            DateTime start = DateTime.UtcNow;

            // Parse query parameter
            string name = req.Query
                .FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
                .Value;

            // Write an event to the customEvents table.
            var evt = new EventTelemetry("Function called");
            evt.Context.User.Id = name;
            this.telemetryClient.TrackEvent(evt);

            // Generate a custom metric, in this case let's use ContentLength.
            this.telemetryClient.GetMetric("contentLength").TrackValue(req.ContentLength);

            // Log a custom dependency in the dependencies table.
            var dependency = new DependencyTelemetry
            {
                Name = "GET api/planets/1/",
                Target = "swapi.co",
                Data = "https://swapi.co/api/planets/1/",
                Timestamp = start,
                Duration = DateTime.UtcNow - start,
                Success = true
            };
            dependency.Context.User.Id = name;
            this.telemetryClient.TrackDependency(dependency);

            return Task.FromResult<IActionResult>(new OkResult());
        }
    }
}

在此範例中,主機會先彙總自訂計量資料,再傳送至 customMetrics 資料表。 若要深入了解,請參閱 Application Insights 中的 GetMetric 文件。

在本機執行時,您必須使用 Application Insights 金鑰將 APPINSIGHTS_INSTRUMENTATIONKEY 設定新增至 local.settings.json 檔案。

不要呼叫 TrackRequestStartOperation<RequestTelemetry>,因為您將會看到對某個函式引動過程所做的重複要求。 Functions 執行階段會自動追蹤要求。

請勿設定 telemetryClient.Context.Operation.Id。 當許多函式同時執行時,此全域設定會導致不正確的相互關聯。 請改為建立新的遙測執行個體 (DependencyTelemetryEventTelemetry),並修改其 Context 屬性。 接著,將遙測執行個體傳入至 TelemetryClient 上對應的 Track 方法 (TrackDependency()TrackEvent()TrackMetric())。 此方法可確保遙測具有目前函式引動過程的正確相互關聯詳細資料。

測試函式

下列文章示範如何在本機執行同處理序 C# 類別庫函式,以供測試之用:

環境變數

若要取得環境變數或應用程式設定值,請使用 System.Environment.GetEnvironmentVariable,如下列程式碼範例所示:

public static class EnvironmentVariablesExample
{
    [FunctionName("GetEnvironmentVariables")]
    public static void Run([TimerTrigger("0 */5 * * * *")]TimerInfo myTimer, ILogger log)
    {
        log.LogInformation($"C# Timer trigger function executed at: {DateTime.Now}");
        log.LogInformation(GetEnvironmentVariable("AzureWebJobsStorage"));
        log.LogInformation(GetEnvironmentVariable("WEBSITE_SITE_NAME"));
    }

    private static string GetEnvironmentVariable(string name)
    {
        return name + ": " +
            System.Environment.GetEnvironmentVariable(name, EnvironmentVariableTarget.Process);
    }
}

本機開發以及於 Azure 執行時,均可從環境變數讀取應用程式設定。 在本機開發時,應用程式設定來自 local.settings.json 檔案中的 Values 集合。 在本機和 Azure 這兩個環境中,GetEnvironmentVariable("<app setting name>") 會擷取具名應用程式設定的值。 例如在本機執行時,如果您的 local.settings.json 檔案包含 { "Values": { "WEBSITE_SITE_NAME": "My Site Name" } },則會傳回 "My Site Name"。

System.Configuration.ConfigurationManager.AppSettings 屬性是用於取得應用程式設定值的替代 API,但建議您使用 GetEnvironmentVariable,如下所示。

執行階段的繫結

在 C# 和其他 .NET 語言中,您可以使用相對於屬性中宣告式繫結的命令式繫結模式。 當繫結參數需要在執行階段而不是設計階段中計算時,命令式繫結非常有用。 利用此模式,您可以快速在您的函式程式碼中繫結至支援的輸入和輸出繫結。

定義命令式繫結,如下所示︰

  • 請勿在函式簽章中加入您所需命令式繫結的屬性。

  • 傳入輸入參數 Binder binderIBinder binder

  • 使用下列 C# 模式來執行資料繫結。

    using (var output = await binder.BindAsync<T>(new BindingTypeAttribute(...)))
    {
        ...
    }
    

    BindingTypeAttribute 是可定義繫結的 .NET 屬性,而 T 是該繫結類型所支援的輸入或輸出類型。 T 不能是 out 參數類型 (例如 out JObject)。 例如,Mobile Apps 資料表輸出繫結支援六個輸出類型,但您只可以搭配命令式繫結使用 ICollector<T>IAsyncCollector<T>

單一屬性範例

下列範例程式碼會使用在執行階段定義的 blob 路徑來建立儲存體 blob 輸出繫結,然後將字串寫入 blob。

public static class IBinderExample
{
    [FunctionName("CreateBlobUsingBinder")]
    public static void Run(
        [QueueTrigger("myqueue-items-source-4")] string myQueueItem,
        IBinder binder,
        ILogger log)
    {
        log.LogInformation($"CreateBlobUsingBinder function processed: {myQueueItem}");
        using (var writer = binder.Bind<TextWriter>(new BlobAttribute(
                    $"samples-output/{myQueueItem}", FileAccess.Write)))
        {
            writer.Write("Hello World!");
        };
    }
}

BlobAttribute 會定義儲存體 blob 輸入或輸出繫結,而 TextWriter 是支援的輸出繫結類型。

多個屬性範例

先前的範例會取得函數應用程式主要儲存體帳戶連接字串的應用程式設定 (也就是 AzureWebJobsStorage)。 您可以指定要用於儲存體帳戶的自訂應用程式設定,方法是新增 StorageAccountAttribute 並將屬性陣列傳遞至 BindAsync<T>()。 使用 Binder 參數,而不是 IBinder。 例如:

public static class IBinderExampleMultipleAttributes
{
    [FunctionName("CreateBlobInDifferentStorageAccount")]
    public async static Task RunAsync(
            [QueueTrigger("myqueue-items-source-binder2")] string myQueueItem,
            Binder binder,
            ILogger log)
    {
        log.LogInformation($"CreateBlobInDifferentStorageAccount function processed: {myQueueItem}");
        var attributes = new Attribute[]
        {
        new BlobAttribute($"samples-output/{myQueueItem}", FileAccess.Write),
        new StorageAccountAttribute("MyStorageAccount")
        };
        using (var writer = await binder.BindAsync<TextWriter>(attributes))
        {
            await writer.WriteAsync("Hello World!!");
        }
    }
}

觸發和繫結

此表顯示主要版本的 Azure Functions 執行階段中所支援的繫結:

類型 1.x 2.x 和更新版本1 觸發程序 輸入 輸出
Blob 儲存體
Azure Cosmos DB
Azure SQL (預覽)
Dapr3
Event Grid
事件中樞
HTTP 和 Webhook
IoT 中心
Kafka2
Mobile Apps
通知中樞
佇列儲存體
RabbitMQ2
SendGrid
服務匯流排
SignalR
表格儲存體
計時器
Twilio

1 從 2.x 版執行階段開始,必須註冊 HTTP 和計時器以外的所有繫結。 請參閱註冊繫結延伸模組

2 觸發程序在取用方案中不受支援。 需要執行階段驅動的觸發程序

3 僅在 Kubernetes、IoT Edge 和其他自我裝載模式中受到支援。

後續步驟