使用 Azure Functions 開發 C# 類別庫函式
重要
內含式模型支援將於 2026 年 11 月 10 日結束。 強烈建議您將應用程式移轉至隔離式背景工作角色模型，以取得完整支援。
本文是在 .NET 類別庫中使用 C# 開發 Azure Functions 的簡介。 這些類別庫可用來搭配 Functions 執行階段執行同處理序。 您的 .NET 函式也可以從 Functions 執行階段執行 _isolated，這提供數個優點。 若要深入了解，請參閱隔離式背景工作角色模型。 如需這兩個模型之間的全面比較，請參閱同處理序模型與隔離式背景工作角色模型之間的差異。
重要
本文支援使用執行階段執行內含式的 .NET 類別庫函式。 您的 C# 函式也可以跨處理序執行，並與 Functions 執行階段隔離。 隔離式背景工作處理序模型是在目前版本的 Functions 執行階段中執行非 LTS 版本的 .NET 和 .NET Framework 應用程式的唯一方式。 若要深入了解，請參閱 .NET 隔離式背景工作處理序函式。 如需隔離式背景工作處理序與內含式 .NET Functions 之間的完整比較，請參閱內含式與隔離式背景工作處理序 .NET Azure Functions 之間的差異。
身為 C# 開發人員，您可能也對下列其中一篇文章感興趣：
| 開始使用 | 概念 | 引導式學習/範例 |
|---|---|---|
Azure Functions 支援 C# 和 C# 指令碼程式設計語言。 如果您需要在 Azure 入口網站中使用 C#的指引，請參閱 C# 指令碼 (.csx) 開發人員參考。
支援的版本
Functions 執行階段的版本支援 .NET 特定版本。 若要深入瞭解 Functions 版本，請參閱 Azure Functions 執行階段版本概觀。 版本支援也取決於函式執行同處理序或隔離式背景工作處理序。
注意
若要瞭解如何變更函數應用程式所使用的 Functions 執行階段版本，請參閱檢視及更新目前的執行階段版本。
下表顯示可與 Functions 特定版本搭配使用的最高層級 .NET 或 .NET Framework。
| Functions 執行階段版本 | 隔離式背景工作模型 | 同處理序模型5 |
|---|---|---|
| Functions 4.x1 | .NET 9.0 (預覽) .NET 8.0 .NET 6.02 .NET Framework 4.83 |
.NET 8.0 .NET 6.02 |
| Functions 1.x4 | n/a | .NET Framework 4.8 |
1 .NET 7 先前在隔離式背景工作角色模型上受到支援，但於 2024 年 5 月 14 日終止正式支援。
2 .NET 6 於 2024 年 11 月 12 日結束正式支援。
3 組建流程也需要使用 .NET SDK。
4 1.x 版的 Azure Functions 執行階段於 2026 年 9 月 14 日結束支援。 如需詳細資訊，請參閱此支援公告。 如需持續的完整支援，您應該將應用程式移轉至 4.x 版。
5 同處理序模型的支援於 2026 年 11 月 10 日結束。 如需詳細資訊，請參閱此支援公告。 如需持續的完整支援，您應該將應用程式移轉至隔離式背景工作角色模型。
如需有關 Azure Functions 版本的最新新聞，包括移除特定舊版次要版本，請持續關注 Azure App Service 公告。
更新至目標 .NET 8
使用同處理序模型的應用程式可以遵循本節中所述的步驟，以 .NET 8 為目標。 不過，如果您選擇執行此選項，您仍應該在 2026 年 11 月 10 日終止同處理序模型的支援之前，開始規劃移轉至隔離式背景工作角色模型。
許多應用程式可以在 Azure 中變更函數應用程式的設定，而不需更新程式碼或重新部署。 若要使用同處理序模型執行 .NET 8，需要三個設定：
- 應用程式設定
FUNCTIONS_WORKER_RUNTIME必須以 "dotnet" 值進行設定。 - 應用程式設定
FUNCTIONS_EXTENSION_VERSION必須以 "~4" 值進行設定。 - 應用程式設定
FUNCTIONS_INPROC_NET8_ENABLED必須以 "1" 值進行設定。 - 您必須更新堆疊組態以參考 .NET 8。
支援 .NET 8 仍使用 Functions 執行階段 4.x 版，且不需要變更設定的執行階段版本。
若要更新本機專案，請先確定您使用的是最新版本的本機工具。 然後確定專案參考 4.4.0 版或更新版本的 Microsoft.NET.Sdk.Functions。 然後，您可以將 TargetFramework 變更為 "net8.0"。 您也必須更新 local.settings.json，以同時將 FUNCTIONS_WORKER_RUNTIME 兩者都設定為 "dotnet"，並將 FUNCTIONS_INPROC_NET8_ENABLED 設定為 "1"。
以下是具有這些變更的最小 project 檔案範例：
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.4.0" />
</ItemGroup>
<ItemGroup>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
<None Update="local.settings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>Never</CopyToPublishDirectory>
</None>
</ItemGroup>
</Project>
以下是具有這些變更的最小 local.settings.json 檔案範例：
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "UseDevelopmentStorage=true",
"FUNCTIONS_INPROC_NET8_ENABLED": "1",
"FUNCTIONS_WORKER_RUNTIME": "dotnet"
}
}
如果您的應用程式使用 Microsoft.Azure.DurableTask.Netherite.AzureFunctions，請確定其以 1.5.3 版或更新版本為目標。 由於 .NET 8 的行為變更，因此具有舊版套件的應用程式會擲回不明確的建構函式例外狀況。
您可能需要根據應用程式的其他相依性版本支援，對應用程式進行其他變更。
Functions 執行階段版本 4.x 提供 .NET 6 和 .NET 8 的同等功能。 同處理序模型未包含與新 .NET 8 功能整合的其他功能或更新。 例如，執行階段不支援索引鍵式服務。 若要充分利用最新的 .NET 8 功能和增強功能，您必須移轉至隔離的背景工作角色模型。
Functions 類別庫專案
在 Visual Studio 中，Azure Functions 專案範本可建立 C# 類別庫專案，其中包含下列檔案：
- host.json - 儲存會影響在本機或 Azure 中執行之專案中所有函式的組態設定。
- local.settings.json - 儲存在本機執行時所使用的應用程式設定和連接字串。 此檔案包含密碼，不會發佈至 Azure 中的函數應用程式。 相反地，將應用程式設定新增至函數應用程式。
當您建置專案時，組建輸出目錄中會產生類似下列範例的資料夾結構：
<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 參數中的方法。
方法簽章參數
方法簽章可包含非用於觸發程序屬性的參數。 以下是幾個可以包含在其中的其他參數：
- 以屬性修飾來加以標示的輸入與輸出繫結。
- 適用於記錄的
ILogger或TraceWriter(僅限 1.x 版) 參數。 - 用於正常關機的
CancellationToken參數。 - 取得觸發程序中繼資料的繫結運算式參數。
函式簽章中的參數順序不重要。 例如，您可以將觸發程序參數放在其他繫結之前或之後，且可以將記錄器參數放在觸發程序或繫結參數之前或之後。
輸出繫結
函式可以使用輸出參數來定義零或多個輸出繫結。
下列範例藉由新增名為 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 所執行。
下列範例顯示具有相同 Sdk 套件之不同目標架構之 .csproj 檔案的相關部分：
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.4.0" />
</ItemGroup>
在 Sdk 套件相依性中的是觸發程序和繫結。 1.x 專案代表 1.x 觸發程序與繫結，因為這些觸發程序與繫結會將目標設定為 .NET Framework，而 4.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 4.x，Core Tools 會隨附於 Azure Functions 與 Web 工作工具延伸模組中。 對於 Functions 1.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 6 和更新版本中使用，且需要 Azure Functions 執行階段 4.0 版。
若要將專案編譯為 ReadyToRun，請新增 <PublishReadyToRun> 與 <RuntimeIdentifier> 元素來更新專案檔。 下列是發佈至 Windows 32 位元函數應用程式的設定。
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
<PublishReadyToRun>true</PublishReadyToRun>
<RuntimeIdentifier>win-x86</RuntimeIdentifier>
</PropertyGroup>
重要
從 .NET 6 開始，已新增複合 ReadyToRun 編譯的支援。 查看 ReadyToRun 跨平台和架構限制。
您也可以從命令列使用 ReadyToRun 來建置應用程式。 如需詳細資訊，請參閱 dotnet publish 中的 -p:PublishReadyToRun=true 選項。
支援的繫結類型
每個繫結都有自己支援的類型；例如，Blob 觸發程序屬性可套用至字串參數、POCO 參數、CloudBlockBlob 參數或任何數個其他支援的類型。 Blob 繫結的繫結參考文章會列出所有支援的參數類型。 如需詳細資訊，請參閱觸發程序和繫結以及每個繫結類型的繫結參考文件。
提示
如果您打算使用 HTTP 或 WebHook 的繫結，請做好規劃，以免因為 HttpClient 具現化不當而耗盡連接埠。 如需詳細資訊，請參閱如何管理 Azure Functions 中的連線。
繫結至方法傳回值
您可以將方法傳回值用於輸出繫結，方法是將屬性套用至方法傳回值。 如需範例，請參閱觸發程序和繫結。
唯有成功的函式執行一律導致傳回值傳遞至輸出繫結時，才使用此傳回值。 否則，使用 ICollector 或 IAsyncCollector，如下一節所示。
撰寫多個輸出值
若要將多個值寫入至輸出繫結，或者如果成功的函式叫用可能未導致將任何項目傳遞至輸出繫結，請使用 ICollector 或 IAsyncCollector 類型。 這些類型是在方法完成時，寫入至輸出繫結的唯寫集合。
這個範例會使用 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
若要讓函式變成非同步，請使用 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 服務匯流排的函式會處理 ServiceBusReceivedMessage 物件的陣列，其代表特定函式叫用所要處理的內送訊息批次：
using Azure.Messaging.ServiceBus;
using System.Threading;
namespace ServiceBusCancellationToken
{
public static class servicebus
{
[FunctionName("servicebus")]
public static void Run([ServiceBusTrigger("csharpguitar", Connection = "SB_CONN")]
ServiceBusReceivedMessage[] messages, CancellationToken cancellationToken, ILogger log)
{
try
{
foreach (var message in messages)
{
if (cancellationToken.IsCancellationRequested)
{
log.LogInformation("A cancellation token was received. Taking precautionary actions.");
//Take precautions like noting how far along you are with processing the batch
log.LogInformation("Precautionary activities --complete--.");
break;
}
else
{
//business logic as usual
log.LogInformation($"Message: {message} was processed.");
}
}
}
catch (Exception ex)
{
log.LogInformation($"Something unexpected happened: {ex.Message}");
}
}
}
}
記錄
您可以在函式程式碼中將輸出寫入記錄，其會在 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 中的新功能，自動將遙測與目前作業相互關聯。 不需要手動設定作業 Id、ParentId 或 Name 欄位。
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 檔案。
不要呼叫 TrackRequest 或 StartOperation<RequestTelemetry>，因為您將會看到對某個函式引動過程所做的重複要求。 Functions 執行階段會自動追蹤要求。
請勿設定 telemetryClient.Context.Operation.Id。 當許多函式同時執行時，此全域設定會導致不正確的相互關聯。 請改為建立新的遙測執行個體 (DependencyTelemetry、EventTelemetry)，並修改其 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 binder或IBinder 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.x1 | 2.x 和更新版本2 | 觸發程序 | 輸入 | 輸出 |
|---|---|---|---|---|---|
| Blob 儲存體 | ✔ | ✔ | ✔ | ✔ | ✔ |
| Azure Cosmos DB | ✔ | ✔ | ✔ | ✔ | ✔ |
| Azure 資料總管 | ✔ | ✔ | ✔ | ||
| Azure SQL | ✔ | ✔ | ✔ | ✔ | |
| Dapr4 | ✔ | ✔ | ✔ | ✔ | |
| Event Grid | ✔ | ✔ | ✔ | ✔ | |
| 事件中樞 | ✔ | ✔ | ✔ | ✔ | |
| HTTP 和 Webhook | ✔ | ✔ | ✔ | ✔ | |
| IoT 中樞 | ✔ | ✔ | ✔ | ||
| Kafka3 | ✔ | ✔ | ✔ | ||
| 行動應用程式 | ✔ | ✔ | ✔ | ||
| 通知中樞 | ✔ | ✔ | |||
| 佇列儲存體 | ✔ | ✔ | ✔ | ✔ | |
| Redis | ✔ | ✔ | |||
| RabbitMQ3 | ✔ | ✔ | ✔ | ||
| SendGrid | ✔ | ✔ | ✔ | ||
| 服務匯流排 | ✔ | ✔ | ✔ | ✔ | |
| SignalR | ✔ | ✔ | ✔ | ✔ | |
| 表格儲存體 | ✔ | ✔ | ✔ | ✔ | |
| 計時器 | ✔ | ✔ | ✔ | ||
| Twilio | ✔ | ✔ | ✔ |
注意：
- Azure Functions 執行階段 1.x 版的支援將於 2026 年 9 月 14 日結束。 強烈建議您將應用程式移轉至 4.x 版，以取得完整支援。
- 從 2.x 版執行階段開始，必須註冊 HTTP 和計時器以外的所有繫結。 請參閱註冊繫結延伸模組。
- 觸發程序在使用量方案中不受支援。 需要執行階段驅動的觸發程序。
- 僅在 Kubernetes、IoT Edge 和其他自我裝載模式中受到支援。