Azure İşlevleri kullanarak C# sınıf kitaplığı işlevleri geliştirme

Önemli

İşlem içi model desteği 10 Kasım 2026'da sona erecektir. Tam destek için uygulamalarınızı yalıtılmış çalışan modeline geçirmenizi kesinlikle öneririz.

Bu makale, .NET sınıf kitaplıklarında C# kullanarak Azure İşlevleri geliştirmeye giriş niteliğindedir. Bu sınıf kitaplıkları İşlevler çalışma zamanı ile işlem içinde çalıştırmak için kullanılır. .NET işlevleriniz alternatif olarak İşlevler çalışma zamanından _isolated çalıştırabilir ve bu da çeşitli avantajlar sunar. Daha fazla bilgi edinmek için yalıtılmış çalışan modeline bakın. Bu iki model arasında kapsamlı bir karşılaştırma için bkz . İşlem içi model ile yalıtılmış çalışan modeli arasındaki farklar.

Önemli

Bu makale, çalışma zamanıyla birlikte işlem halinde çalışan .NET sınıf kitaplığı işlevlerini destekler. C# işlevleriniz de işlem dışı çalışabilir ve İşlevler çalışma zamanından yalıtılabilir. Yalıtılmış çalışan işlem modeli, İşlevler çalışma zamanının geçerli sürümlerinde .NET ve .NET Framework uygulamalarının LTS dışı sürümlerini çalıştırmanın tek yoludur. Daha fazla bilgi edinmek için bkz . .NET yalıtılmış çalışan işlemi işlevleri. Yalıtılmış çalışan işlemi ile işlem içi .NET İşlevleri arasında kapsamlı bir karşılaştırma için bkz. .NET Azure İşlevleri çalışan işlemi ile yalıtma arasındaki farklar.

C# geliştiricisi olarak aşağıdaki makalelerden biriyle de ilgilenebilirsiniz:

Başlarken Kavramlar Destekli öğrenme/örnekler

Azure İşlevleri C# ve C# betik programlama dillerini destekler. Azure portalında C# kullanma yönergelerini arıyorsanız bkz. C# betiği (.csx) geliştirici başvurusu.

Desteklenen sürümler

İşlevler çalışma zamanının sürümleri .NET'in belirli sürümlerini destekler. İşlev sürümleri hakkında daha fazla bilgi edinmek için bkz. Azure İşlevleri çalışma zamanı sürümlerine genel bakış. Sürüm desteği, işlevlerinizin işlem içinde mi yoksa yalıtılmış çalışan işlemi mi çalıştırdığına da bağlıdır.

Not

İşlev uygulamanız tarafından kullanılan İşlevler çalışma zamanı sürümünü değiştirmeyi öğrenmek için bkz . Geçerli çalışma zamanı sürümünü görüntüleme ve güncelleştirme.

Aşağıdaki tabloda, İşlevler'in belirli bir sürümüyle kullanılabilecek en yüksek .NET veya .NET Framework düzeyi gösterilmektedir.

İşlevler çalışma zamanı sürümü Yalıtılmış çalışan modeli İşlem içi model5
İşlevler 4.x .NET 8.0
.NET 7.01
.NET 6.02
.NET Framework 4.83
.NET 6.02
İşlevler 1.x4 yok .NET Framework 4.8

1 .NET 7, 14 Mayıs 2024'te resmi desteğin sonuna ulaşıyor.
2 .NET 6, 12 Kasım 2024'te resmi desteğin sonuna ulaşıyor.
3 Derleme işlemi ayrıca .NET SDK'sını gerektirir. 4 Azure İşlevleri çalışma zamanının 1.x sürümü için destek 14 Eylül 2026'da sona erer. Daha fazla bilgi için bu destek duyurusna bakın. Sürekli tam destek için uygulamalarınızı 4.x sürümüne geçirmeniz gerekir.
5 İşlem içi model için destek 10 Kasım 2026'da sona eriyor. Daha fazla bilgi için bu destek duyurusna bakın. Sürekli tam destek için uygulamalarınızı yalıtılmış çalışan modeline geçirmeniz gerekir.

Belirli eski ikincil sürümlerin kaldırılması da dahil olmak üzere Azure İşlevleri sürümlerle ilgili en son haberler için Azure Uygulaması Hizmet duyurularını izleyin.

İşlevler sınıf kitaplığı projesi

Visual Studio'da, Azure İşlevleri proje şablonu aşağıdaki dosyaları içeren bir C# sınıf kitaplığı projesi oluşturur:

  • host.json - Yerel olarak veya Azure'da çalıştırılırken projedeki tüm işlevleri etkileyen yapılandırma ayarlarını depolar.
  • local.settings.json : Yerel olarak çalıştırılırken kullanılan uygulama ayarlarını ve bağlantı dizesi depolar. Bu dosya gizli diziler içerir ve Azure'daki işlev uygulamanızda yayımlanmaz. Bunun yerine, işlev uygulamanıza uygulama ayarları ekleyin.

Projeyi oluşturduğunuzda, derleme çıktı dizininde aşağıdaki örneğe benzer bir klasör yapısı oluşturulur:

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

Bu dizin, Azure'daki işlev uygulamanıza dağıtılan dizindir. İşlevler çalışma zamanının 2.x sürümünde gereken bağlama uzantıları projeye NuGet paketleri olarak eklenir.

Önemli

Derleme işlemi, her işlev için bir function.json dosyası oluşturur. Bu function.json dosyasının doğrudan düzenlenmesi amaçlanmamıştır. Bu dosyayı düzenleyerek bağlama yapılandırmasını değiştiremez veya işlevi devre dışı bırakamazsınız. Bir işlevi devre dışı bırakma hakkında bilgi edinmek için bkz . İşlevleri devre dışı bırakma.

İşlev olarak tanınan yöntemler

Bir sınıf kitaplığında işlev, aşağıdaki örnekte gösterildiği gibi ve tetikleyici özniteliğine sahip FunctionName bir yöntemdir:

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

FunctionName özniteliği, yöntemini bir işlev giriş noktası olarak işaretler. Ad proje içinde benzersiz olmalı, harfle başlamalıdır ve yalnızca en fazla 127 karakter uzunluğunda harf, _sayı, ve -içermelidir. Proje şablonları genellikle adlı Runbir yöntem oluşturur, ancak yöntem adı geçerli bir C# yöntemi adı olabilir. Yukarıdaki örnekte kullanılan statik bir yöntem gösterilmektedir, ancak işlevlerin statik olması gerekmez.

Tetikleyici özniteliği tetikleyici türünü belirtir ve giriş verilerini bir yöntem parametresine bağlar. Örnek işlev bir kuyruk iletisi tarafından tetikler ve kuyruk iletisi parametresindeki myQueueItem yöntemine geçirilir.

Yöntem imzası parametreleri

Yöntem imzası tetikleyici özniteliğiyle kullanılandan farklı parametreler içerebilir. Ekleyebileceğiniz diğer parametrelerden bazıları şunlardır:

İşlev imzasında parametrelerin sırası önemli değildir. Örneğin, tetikleyici parametrelerini diğer bağlamalardan önce veya sonra koyabilirsiniz ve günlükçü parametresini tetikleyici veya bağlama parametrelerinin önüne veya arkasına koyabilirsiniz.

Çıkış bağlamaları

Bir işlevin çıkış parametreleri kullanılarak tanımlanan sıfır veya birden çok çıkış bağlaması olabilir.

Aşağıdaki örnek, adlı myQueueItemCopybir çıkış kuyruğu bağlaması ekleyerek öncekini değiştirir. İşlev, işlevi tetikleyen iletinin içeriğini farklı bir kuyruktaki yeni bir iletiye yazar.

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

Çıkış bağlamalarına atanan değerler, işlevden çıkıldığında yazılır. Birden çok çıkış parametresine değer atayarak işlevde birden fazla çıkış bağlaması kullanabilirsiniz.

Bağlama başvuru makaleleri (örneğin Depolama kuyruklar), tetikleyici, giriş veya çıkış bağlama öznitelikleriyle hangi parametre türlerini kullanabileceğinizi açıklar.

Bağlama ifadeleri örneği

Aşağıdaki kod, bir uygulama ayarından izlenecek kuyruğun adını alır ve parametresinde insertionTime kuyruk iletisi oluşturma süresini alır.

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

Otomatik oluşturulan function.json

Derleme işlemi, derleme klasöründeki bir işlev klasöründe function.json dosyası oluşturur. Daha önce belirtildiği gibi, bu dosyanın doğrudan düzenlenmesi amaçlanmamıştır. Bu dosyayı düzenleyerek bağlama yapılandırmasını değiştiremez veya işlevi devre dışı bırakamazsınız.

Bu dosyanın amacı, Tüketim planındaki ölçeklendirme kararları için kullanılacak ölçek denetleyicisine bilgi sağlamaktır. Bu nedenle, dosya yalnızca tetikleyici bilgilerine sahiptir, giriş/çıkış bağlamalarına sahip değildir.

Oluşturulan function.json dosyası, çalışma zamanına function.json yapılandırma yerine bağlamalar için .NET özniteliklerini kullanmasını bildiren bir configurationSource özellik içerir. Bir örnek aşağıda verilmiştir:

{
  "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 dosya oluşturma işlemi, Microsoft.NET.Sdk.Functions NuGet paketi tarafından gerçekleştirilir.

Aşağıdaki örnekte, dosyaların aynı Sdk paketin .csproj farklı hedef çerçevelerine sahip ilgili bölümleri gösterilmektedir:

<PropertyGroup>
  <TargetFramework>net6.0</TargetFramework>
  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
</ItemGroup>

Sdk Paket bağımlılıkları arasında tetikleyiciler ve bağlamalar bulunur. 1.x projesi, 1.x tetikleyicilerine ve bağlamalarına başvurur çünkü bu tetikleyiciler ve bağlamalar .NET Framework'i hedeflerken, 4.x tetikleyicileri ve bağlamaları .NET Core'ı hedefler.

Paket Sdk ayrıca Newtonsoft.Json'a ve dolaylı olarak WindowsAzure.Depolama'a bağlıdır. Bu bağımlılıklar, projenizin, projenin hedeflediğinden İşlevler çalışma zamanı sürümüyle çalışan paketlerin sürümlerini kullandığından emin olur. Örneğin, Newtonsoft.Json .NET Framework 4.6.1 için sürüm 11'e sahiptir, ancak .NET Framework 4.6.1'i hedefleyen İşlevler çalışma zamanı yalnızca 9.0.1 ile Newtonsoft.Json uyumludur. Bu nedenle bu projedeki işlev kodunuzun da 9.0.1 kullanması Newtonsoft.Json gerekir.

için Microsoft.NET.Sdk.Functions kaynak kodu GitHub deposunda azure-functions-vs-build-sdk kullanılabilir.

Yerel çalışma zamanı sürümü

Visual Studio, İşlevler projelerini yerel bilgisayarınızda çalıştırmak için Azure İşlevleri Temel Araçları'nı kullanır. Çekirdek Araçlar, İşlevler çalışma zamanı için bir komut satırı arabirimidir.

Core Tools'u Windows installer (MSI) paketini veya npm'yi kullanarak yüklerseniz, Visual Studio tarafından kullanılan Core Tools sürümünü etkilemez. İşlevler çalışma zamanı sürüm 1.x için Visual Studio, Çekirdek Araçlar sürümlerini %USERPROFILE%\AppData\Local\Azure.Functions.Cli içinde depolar ve burada depolanan en son sürümü kullanır. İşlevler 4.x için, Temel Araçlar Azure İşlevleri ve Web İşleri Araçları uzantısına dahil edilir. İşlevler 1.x için, bir İşlevler projesi çalıştırdığınızda konsol çıkışında hangi sürümün kullanıldığını görebilirsiniz:

[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

İşlev uygulamanızı ReadyToRun ikili dosyaları olarak derleyebilirsiniz. ReadyToRun, Bir Tüketim planında çalışırken soğuk başlatmanın etkisini azaltmaya yardımcı olmak için başlangıç performansını geliştirebilen bir önceden derleme biçimidir.

ReadyToRun , .NET 6 ve sonraki sürümlerde kullanılabilir ve Azure İşlevleri çalışma zamanının 4.0 sürümünü gerektirir.

Projenizi ReadyToRun olarak derlemek için ve <RuntimeIdentifier> öğelerini ekleyerek proje dosyanızı güncelleştirin<PublishReadyToRun>. Aşağıda, bir Windows 32 bit işlev uygulamasında yayımlama yapılandırması yer alır.

<PropertyGroup>
  <TargetFramework>net6.0</TargetFramework>
  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
  <PublishReadyToRun>true</PublishReadyToRun>
  <RuntimeIdentifier>win-x86</RuntimeIdentifier>
</PropertyGroup>

Önemli

.NET 6'dan başlayarak Bileşik ReadyToRun derlemesi desteği eklendi. ReadyToRun Platformlar arası ve mimari kısıtlamalarına göz atın.

Uygulamanızı komut satırından ReadyToRun ile de oluşturabilirsiniz. Daha fazla bilgi için içindeki dotnet publishseçeneğine -p:PublishReadyToRun=true bakın.

Bağlamalar için desteklenen türler

Her bağlamanın kendi desteklenen türleri vardır; örneğin, bir blob tetikleyici özniteliği bir dize parametresine, POCO parametresine, CloudBlockBlob parametreye veya desteklenen diğer çeşitli türlerden herhangi birine uygulanabilir. Blob bağlamaları için bağlama başvuru makalesinde desteklenen tüm parametre türleri listelenir. Daha fazla bilgi için bkz . Tetikleyiciler ve bağlamalar ve her bağlama türü için bağlama başvuru belgeleri.

İpucu

HTTP veya Web Kancası bağlamalarını kullanmayı planlıyorsanız, yanlış örnek oluşturmanın neden olabileceği bağlantı noktası tükenmesini önlemeyi planlayın HttpClient. Daha fazla bilgi için bkz. Azure İşlevleri'da bağlantıları yönetme.

Yöntem dönüş değerine bağlama

Özniteliğini yöntem dönüş değerine uygulayarak bir çıkış bağlaması için yöntem dönüş değeri kullanabilirsiniz. Örnekler için bkz . Tetikleyiciler ve bağlamalar.

Dönüş değerini yalnızca başarılı bir işlev yürütmesi her zaman çıkış bağlamasına geçirmek için bir dönüş değeriyle sonuçlanırsa kullanın. Aksi takdirde, aşağıdaki bölümde gösterildiği gibi veya IAsyncCollectorkullanınICollector.

Birden çok çıkış değeri yazma

Çıkış bağlamasına birden çok değer yazmak için veya başarılı bir işlev çağrısı çıktı bağlamasına herhangi bir şey geçirilmediyse veya IAsyncCollector türlerini kullanınICollector. Bu türler, yöntem tamamlandığında çıkış bağlamasına yazılan salt yazma koleksiyonlarıdır.

Bu örnek kullanarak ICollectoraynı kuyruğa birden çok kuyruk iletisi yazar:

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

Zaman Uyumsuz

bir işlevi zaman uyumsuz hale getirmek için anahtar sözcüğünü async kullanın ve bir Task nesne döndürin.

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

Zaman uyumsuz işlevlerde parametreleri kullanamazsınız out . Çıkış bağlamaları için bunun yerine işlev dönüş değerini veya toplayıcı nesnesini kullanın.

İptal belirteçleri

İşlev bir CancellationToken parametresini kabul edebilir ve bu parametre, işletim sisteminin işlev sonlandırılacakken kodunuzu bildirmesini sağlar. İşlevin verileri tutarsız bir durumda bırakabilecek şekilde beklenmedik şekilde sonlandırılmadığından emin olmak için bu bildirimi kullanabilirsiniz.

İletileri toplu olarak işleyen bir işleviniz olduğunda bu durumu göz önünde bulundurun. Aşağıdaki Azure Service Bus ile tetiklenen işlev, belirli bir işlev çağrısı tarafından işlenecek bir toplu gelen iletileri temsil eden bir ServiceBusReceivedMessage nesneleri dizisini işler:

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

Günlük Kaydı

İşlev kodunuzda, Application Analizler'da izleme olarak görünen günlüklere çıkış yazabilirsiniz. Günlüklere yazmanın önerilen yolu, genellikle adlı logILogger türünde bir parametre eklemektir. İşlevler çalışma zamanının TraceWriter1.x sürümü, Application Analizler'a da yazar, ancak yapılandırılmış günlüğü desteklemez. Bu veriler Uygulama Analizler tarafından yakalanmadığından günlüklerinizi yazmak için kullanmayınConsole.Write.

ILogger

İşlev tanımınıza yapılandırılmış günlüğü destekleyen bir ILogger parametresi ekleyin.

Bir ILogger nesnesiyle, günlükleri oluşturmak için ILogger'da uzantı yöntemlerini çağırırsınızLog<level>. Aşağıdaki kod, kategoriye Function.<YOUR_FUNCTION_NAME>.User.sahip günlükleri Information yazar:

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

İşlevlerin ILoggernasıl uyguladığı hakkında daha fazla bilgi edinmek için bkz . Telemetri verilerini toplama. Bir örnek kullandığınız ILogger varsayıldığında önekli Function kategoriler. Bunun yerine bir ILogger<T>kullanmayı seçerseniz, kategori adı temel Talabilir.

Yapılandırılmış günlüğe kaydetme

Yer tutucuların adları değil sırası, günlük iletisinde hangi parametrelerin kullanılacağını belirler. Aşağıdaki koda sahip olduğunuzu varsayalım:

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

Aynı ileti dizesini tutar ve parametrelerin sırasını tersine çevirirseniz, sonuçta elde edilen ileti metninde değerler yanlış yerlerde olur.

Yer tutucular, yapılandırılmış günlük kaydı gerçekleştirebilmeniz için bu şekilde işlenir. Uygulama Analizler, parametre adı-değer çiftlerini ve ileti dizesini depolar. Sonuç, ileti bağımsız değişkenlerinin sorgulayabileceğiniz alanlara dönüşmesidir.

Günlükçü yöntemi çağrınız önceki örneğe benziyorsa alanını customDimensions.prop__rowKeysorgulayabilirsiniz. Çalışma zamanının prop__ eklediği alanlar ile işlev kodunuzun eklediği alanlar arasında çakışma olmadığından emin olmak için ön ek eklenir.

alanına customDimensions.prop__{OriginalFormat}başvurarak özgün ileti dizesini de sorgulayabilirsiniz.

Verilerin örnek JSON gösterimi aşağıda verilmişti customDimensions :

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

Özel telemetriyi günlüğe kaydetme

İşlevlerinizdeki özel telemetri verilerini Application Analizler: Microsoft.Azure.WebJobs.Logging.Application Analizler uygulamasına göndermek için kullanabileceğiniz Uygulama Analizler SDK'sının İşlevlere özgü bir sürümü vardır. Bu paketi yüklemek için komut isteminden aşağıdaki komutu kullanın:

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

Bu komutta öğesini bu paketin yüklü Microsoft.Azure.WebJobs sürümünüzü destekleyen bir sürümüyle değiştirin<VERSION>.

Aşağıdaki C# örnekleri özel telemetri API'sini kullanır. Örnek bir .NET sınıf kitaplığına yöneliktir, ancak Application Analizler kodu C# betiği için aynıdır.

Çalışma zamanının 2.x ve sonraki sürümleri, telemetriyi geçerli işlemle otomatik olarak ilişkilendirmek için Application Analizler'daki daha yeni özellikleri kullanır. İşlemi , ParentIdveya Name alanlarını el ile ayarlamanız Idgerekmez.

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

Bu örnekte, özel ölçüm verileri customMetrics tablosuna gönderilmeden önce konak tarafından toplanır. Daha fazla bilgi edinmek için Uygulama Analizler'daki GetMetric belgelerine bakın.

Yerel olarak çalışırken, Application Analizler anahtarıyla ayarı local.settings.json dosyasına eklemeniz APPINSIGHTS_INSTRUMENTATIONKEY gerekir.

İşlev çağrısı için yinelenen istekler göreceğiniz için veya StartOperation<RequestTelemetry> çağrısı TrackRequest yapmayın. İşlevler çalışma zamanı istekleri otomatik olarak izler.

ayarlamayın telemetryClient.Context.Operation.Id. Bu genel ayar, birçok işlev aynı anda çalışırken yanlış bağıntıya neden olur. Bunun yerine yeni bir telemetri örneği (DependencyTelemetry, EventTelemetry) oluşturun ve özelliğini Context değiştirin. Ardından telemetri örneğini (TrackDependency(), TrackEvent(), TrackMetric()) üzerindeki TelemetryClient ilgili Track yönteme geçirin. Bu yöntem, telemetrinin geçerli işlev çağrısı için doğru bağıntı ayrıntılarına sahip olmasını sağlar.

İşlevleri test etme

Aşağıdaki makalelerde test amacıyla işlem içi C# sınıf kitaplığı işlevinin yerel olarak nasıl çalıştırılacakları gösterilmektedir:

Ortam değişkenleri

Ortam değişkeni veya uygulama ayarı değeri almak için, aşağıdaki kod örneğinde gösterildiği gibi kullanın 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);
    }
}

Uygulama ayarları hem yerel olarak geliştirirken hem de Azure'da çalışırken ortam değişkenlerinden okunabilir. Yerel olarak geliştirme yaparken, uygulama ayarları local.settings.json dosyasındaki koleksiyondan Values gelir. Yerel ve Azure gibi her iki ortamda da GetEnvironmentVariable("<app setting name>") adlandırılmış uygulama ayarının değerini alır. Örneğin, yerel olarak çalıştırdığınızda, local.settings.json dosyanız içeriyorsa { "Values": { "WEBSITE_SITE_NAME": "My Site Name" } }"Sitem Adı" döndürülür.

System.Configuration.ConfigurationManager.App Ayarlar özelliği, uygulama ayarı değerlerini almak için alternatif bir API'dir, ancak burada gösterildiği gibi kullanmanızı GetEnvironmentVariable öneririz.

Çalışma zamanında bağlama

C# ve diğer .NET dillerinde, özniteliklerdeki bildirim temelli bağlamaların aksine kesinlik temelli bağlama deseni kullanabilirsiniz. Kesinlik temelli bağlama, bağlama parametrelerinin tasarım zamanından ziyade çalışma zamanında hesaplanması gerektiğinde yararlıdır. Bu desenle, işlev kodunuzda desteklenen giriş ve çıkış bağlamalarını anında bağlayabilirsiniz.

Kesinlik temelli bağlamayı aşağıdaki gibi tanımlayın:

  • İstediğiniz kesinlik temelli bağlamalar için işlev imzasında bir öznitelik eklemeyin.

  • Bir giriş parametresi Binder binder veya IBinder bindergeçirin.

  • Veri bağlamayı gerçekleştirmek için aşağıdaki C# desenini kullanın.

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

    BindingTypeAttribute bağlamanızı tanımlayan .NET özniteliğidir ve T bu bağlama türü tarafından desteklenen bir giriş veya çıkış türüdür. T bir out parametre türü (örneğin out JObject) olamaz. Örneğin, Mobile Apps tablosu çıkış bağlaması altı çıkış türünü destekler, ancak kesinlik temelli bağlama ile yalnızca ICollector<T> veya IAsyncCollector<T> kullanabilirsiniz.

Tek öznitelik örneği

Aşağıdaki örnek kod, çalışma zamanında tanımlanan blob yolu ile Depolama bir blob çıkış bağlaması oluşturur ve ardından bloba bir dize yazar.

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, Depolama blob giriş veya çıkış bağlamasını tanımlar ve TextWriter desteklenen bir çıkış bağlama türüdür.

Birden çok öznitelik örneği

Yukarıdaki örnek, işlev uygulamasının ana Depolama hesabı bağlantı dizesi (yaniAzureWebJobsStorage) için uygulama ayarını alır. Depolama AccountAttribute öğesini ekleyerek ve öznitelik dizisini içine BindAsync<T>()geçirerek Depolama hesabı için kullanılacak özel bir uygulama ayarı belirtebilirsiniz. Binder parametresini değilIBinder, parametresini kullanın. Örneğin:

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

Tetikleyiciler ve bağlamalar

Bu tabloda, Azure İşlevleri çalışma zamanının ana sürümlerinde desteklenen bağlamalar gösterilmektedir:

Tür 1.x1 2.x ve üzeri2 Tetikle Girdi Çıktı
Blob depolama
Azure Cosmos DB
Azure Veri Gezgini
Azure SQL
Dapr4
Event Grid
Event Hubs
HTTP & web kancaları
IoT Hub
Kafka3
Mobile Apps
Notification Hubs
Kuyruk depolama
Redis
RabbitMQ3
SendGrid
Service Bus
SignalR
Tablo depolama
Zamanlayıcı
Twilio

114 Eylül 2026'da Azure İşlevleri çalışma zamanının 1.x sürümü için destek sona erecektir. Tam destek için uygulamalarınızı 4.x sürümüne geçirmenizi kesinlikle öneririz.

2 Sürüm 2.x çalışma zamanından itibaren HTTP ve Zamanlayıcı dışındaki tüm bağlamaların kaydedilmesi gerekir. Bkz . Bağlama uzantılarını kaydetme.

3 Tetikleyiciler Tüketim planında desteklenmez. Çalışma zamanı temelli tetikleyiciler gerektirir.

4 Yalnızca Kubernetes, IoT Edge ve diğer şirket içinde barındırılan modlarda desteklenir.

Sonraki adımlar