Azure Functions runtime 1.x legacy reference

Von Bedeutung

Die Unterstützung für Version 1.x der Azure Functions-Laufzeit endete am 14. September 2026. Migrieren Sie Ihre Apps zur Version 4.x , um den vollständigen Support zu ermöglichen.

Dieser Artikel bewahrt wichtige historische Informationen und verlinkt zu detaillierten Referenzen für Funktionsanwendungen, die weiterhin Runtime 1.x verwenden. Verwende Runtime 1.x nicht für neue Funktions-Apps.

Laufzeit-1.x-Scope

Azure Functions Runtime 1.x endete am 14. September 2026 und wird für neue oder bestehende Funktionsanwendungen nicht unterstützt. Laufzeit 1.x hatte folgende Eigenschaften:

  • Es lief nur unter Windows.
  • Es unterstützte C#-Apps, die auf das .NET Framework und JavaScript-Apps abzielten.
  • C#-Apps liefen im Prozess. Runtime 1.x unterstützte das isolierte Worker-Modell nicht.
  • Für die lokale Entwicklung wurde Version 1.x von Azure Functions Core Tools verwendet. Core Tools 1.x läuft nur unter Windows.
  • Die Laufzeit umfasste die unterstützten Bindungen. Spätere Laufzeitversionen verwenden separat versionierte Bindungserweiterungen oder Erweiterungsbündel.

Versionen von Laufzeit-, Erweiterungs- und Programmiermodellen

Die Azure Functions-Laufzeitversion ist nicht dieselbe wie die Versionen, die von Bindungserweiterungen, Erweiterungsbündeln oder Sprachprogrammiermodellen verwendet werden. Ein Versionslabel auf einer anderen Komponente zeigt nicht an, dass eine App Azure Functions Runtime 1.x verwendet. Beispiel:

  • Die Programmiermodelle von Python v1 und v2 laufen auf Runtime 4.x.
  • Die Programmiermodelle Node.js v3 und v4 laufen auf Laufzeit 4.x.
  • Erweiterungsbundle- und Binding-Erweiterungspaket-Versionen sind unabhängig von der Laufzeitversion.

Migration zu Runtime 4.x

Um eine App wieder voll unterstützt zu machen, migriere sie von Runtime 1.x zu Runtime 4.x. Der Migrationsleitfaden behandelt folgende Aufgaben:

  • Identifizieren Sie Anwendungen, die auf Laufzeit 1.x abzielen.
  • Wählen Sie ein unterstütztes Ziel für C# oder JavaScript.
  • Aktualisieren Sie das Projekt, die Bindungen, die App-Einstellungen und host.json Datei.
  • Teste die App lokal und aktualisiere die Funktions-App in Azure.

Ändere nicht nur die FUNCTIONS_EXTENSION_VERSION App-Einstellungen. Laufzeit-Upgrades können Projekt-, Code-, Bindungs- und Konfigurationsänderungen erfordern.

App-Einstellungen speziell für Runtime 1.x

Die veraltete AzureWebJobsDashboard Einstellung wird nur von Runtime 1.x unterstützt. Es enthält eine optionale allgemeine Speicherkonto-Verbindungszeichenfolge, die zur Speicherung von Logs und zur Anzeige im Monitor-Tab im Azure-Portal verwendet wird.

Schlüssel Beispielwert
AzureWebJobsDashboard DefaultEndpointsProtocol=https;AccountName=...

Runtime 1.x unterstützt die AZURE_FUNCTIONS_ENVIRONMENT App-Einstellung nicht.

Der Wert FUNCTIONS_EXTENSION_VERSION~1 pinnt eine Funktions-App an Runtime 1.x. Die Speicherung von Dateisystemschlüsseln (AzureWebJobsSecretStorageType=files) ist der Standard.

Die Site-Eigenschaft functionsRuntimeAdminIsolationEnabled ist in Runtime 1.x nicht verfügbar. Die Einstellung FUNCTIONS_V2_COMPATIBILITY_MODE gilt nicht für Runtime 1.x-Apps.

Project- und Sprachunterschiede

Runtime 1.x C#-Klassenbibliotheksprojekte zielten auf das .NET Framework ab und verwendeten die Version 1.x des Microsoft.NET.Sdk.Functions Pakets. Sie könnten sie zum Holzeinschlag nutzen TraceWriter . Für das aktuelle C#-Projektmodell und Migrationsüberlegungen siehe den .NET-Klassenbibliotheks-Entwicklerleitfaden und den Runtime 1.x-Migrationsguide.

C#-Klassenbibliotheksprojekte

Das folgende Beispiel zeigt die relevanten Teile einer Laufzeit-1.x-Projektdatei:

<PropertyGroup>
  <TargetFramework>net48</TargetFramework>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
</ItemGroup>

Die Microsoft.NET.Sdk.Functions Paketabhängigkeiten beinhalten Trigger und Bindungen. Ein 1.x-Projekt bezieht sich auf 1.x-Trigger und -Bindungen, weil sie auf das .NET Framework abzielen. Das Paket hängt auch von Newtonsoft.Json ab und indirekt von WindowsAzure.Storage. Diese Abhängigkeiten stellen sicher, dass das Projekt Versionen verwendet, die mit der angestrebten Functions-Laufzeit kompatibel sind. Zum Beispiel ist die Functions-Laufzeit, die auf .NET Framework 4.6.1 abzielt, mit 9.0.1 kompatibel, nicht mit Newtonsoft.Json Version 11.

Laufzeit 1.x wird für Application Insights Logging verwendet TraceWriter . TraceWriter Unterstützt kein strukturiertes Logging.

Das folgende Beispiel erzeugt ein TelemetryClient und verwendet TrackEvent, TrackMetric, und TrackDependency um benutzerdefinierte Telemetrie aufzuzeichnen. Außerdem wird der Funktionsausführungskontext verwendet, um die benutzerdefinierte Telemetrie mit dem aktuellen Aufruf zu korrelieren.

Beispiel für benutzerdefinierte Telemetrie

using System;
using System.Linq;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace functionapp0915
{
	public static class HttpTrigger2
	{
		private static string key = TelemetryConfiguration.Active.InstrumentationKey =
			Environment.GetEnvironmentVariable(
				"APPINSIGHTS_INSTRUMENTATIONKEY", EnvironmentVariableTarget.Process);

		private static TelemetryClient telemetryClient =
			new TelemetryClient() { InstrumentationKey = key };

		[FunctionName("HttpTrigger2")]
		public static async Task<HttpResponseMessage> Run(
			[HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)]
			HttpRequestMessage req, ExecutionContext context, ILogger log)
		{
			log.LogInformation("C# HTTP trigger function processed a request.");
			DateTime start = DateTime.UtcNow;
			string name = req.GetQueryNameValuePairs()
				.FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
				.Value;
			dynamic data = await req.Content.ReadAsAsync<object>();
			name = name ?? data?.name;

			var evt = new EventTelemetry("Function called");
			UpdateTelemetryContext(evt.Context, context, name);
			telemetryClient.TrackEvent(evt);

			var metric = new MetricTelemetry("Test Metric", DateTime.Now.Millisecond);
			UpdateTelemetryContext(metric.Context, context, name);
			telemetryClient.TrackMetric(metric);

			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
			};
			UpdateTelemetryContext(dependency.Context, context, name);
			telemetryClient.TrackDependency(dependency);
		}

		private static void UpdateTelemetryContext(
			TelemetryContext context,
			ExecutionContext functionContext,
			string userName)
		{
			context.Operation.Id = functionContext.InvocationId.ToString();
			context.Operation.ParentId = functionContext.InvocationId.ToString();
			context.Operation.Name = functionContext.FunctionName;
			context.User.Id = userName;
		}
	}
}

Runtime 1.x unterstützte außerdem das C#-Skript (.csx) und JavaScript-Funktionen. Das C#-Skript ist nicht spezifisch für Laufzeit 1.x, also nutze die C#-Skriptentwickler-Referenz für allgemeine Skriptanleitung. Verwenden Sie den Migrationsleitfaden für laufzeitspezifische Änderungen.

Beispiele für die frühere C#-Syntax finden Sie in den Laufzeit-1.x-Funktionstemplates.

C#-Skriptassemblierungen und -pakete

In Runtime 1.x C#-Skriptfunktionen konnte man folgende Assemblies einfach mit dem Namen referenzieren:

  • Newtonsoft.Json
  • Microsoft.WindowsAzure.Storage
  • Microsoft.ServiceBus
  • Microsoft.AspNet.WebHooks.Receivers
  • Microsoft.AspNet.WebHooks.Common

Runtime 1.x verwendete eine project.json-Datei , um Abhängigkeiten zu definieren. Das folgende Beispiel fügt das Microsoft.ProjectOxford.Face NuGet-Paket hinzu:

{
	"frameworks": {
		"net46": {
			"dependencies": {
				"Microsoft.ProjectOxford.Face": "1.1.0"
			}
		}
	}
}

Erweiterungsbündel werden von Runtime 1.x nicht unterstützt. Um einen benutzerdefinierten NuGet-Feed zu verwenden, gib den Feed in einer NuGet.Config-Datei im Funktions-App-Rootordner an. Weitere Informationen finden Sie unter Konfigurieren des NuGet-Verhaltens.

Lokale Entwicklung mit Core Tools 1.x

Version 1.x von Azure Functions Core Tools ist mit Runtime 1.x gepaart und läuft ausschließlich unter Windows. Um die Laufzeit zu starten, liefst func host startdu . Für aktuelle lokale Entwicklungsratschläge siehe Develop Azure Functions local using Core Tools.

Visual Studio speicherte Runtime 1.x Core Tools Versionen in %USERPROFILE%\AppData\Local\Azure.Functions.Cli und verwendete die neueste Version, die dort gespeichert war. Man konnte die ausgewählte Version beim Ausführen des Projekts in der Konsolenausgabe sehen:

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

Laufzeit 1.x host.json Referenz

Dashost.jsonSchema und die Einstellungen wurden nach Laufzeit 1.x geändert. Sehen Sie sich die Laufzeit-1.x-host.json-Referenz bei der Überprüfung einer bestehenden Konfiguration an und vergleichen Sie sie während der Migration mit der aktuellen host.json-Referenz .

Überwachen Sie Laufzeit-1.x-Apps mit Application Insights

Runtime 1.x verwendet die folgenden Anwendungs-Insights-Logkategorien:

Kategorie Table Description
Function Spuren Vom Benutzer generierte Protokolle mit einer beliebigen Protokollstufe.
Host.Aggregator customMetrics Zählungen und Durchschnitte der Funktionsaufrufe über einen konfigurierbaren Zeitraum. Standardmäßig sind 30 Sekunden oder 1.000 Ergebnisse, je nachdem, was zuerst eintritt. Diese Protokolle werden auf der Stufe Information geschrieben.
Host.Executor Spuren Funktion startete und vervollständigte Protokolle. Erfolgreiche Durchläufe verwenden Information, Ausnahmen verwenden Error, und Bedingungen wie Giftwarteschlangen-Nachrichten verwenden Warning.
Host.Results Anfragen Erfolg oder Misserfolg von Funktionsausführungen. Diese Protokolle werden auf der Stufe Information geschrieben.

Konfigurieren von Protokollstufen

Laufzeit 1.x konfiguriert Log-Level unter logger.categoryFilterhost.json:

{
	"logger": {
		"categoryFilter": {
			"defaultLevel": "Warning",
			"categoryLevels": {
				"Host.Results": "Information",
				"Host.Aggregator": "Trace",
				"Function": "Information"
			}
		}
	}
}

Wenn mehrere Kategoriennamen mit derselben Zeichenkette beginnen, wird zuerst die spezifischere Kategorie abgeglichen. Das folgende Beispiel protokolliert alles außer Host.Aggregator auf der Ebene Error :

{
	"logger": {
		"categoryFilter": {
			"defaultLevel": "Information",
			"categoryLevels": {
				"Host": "Error",
				"Function": "Error",
				"Host.Aggregator": "Information"
			}
		}
	}
}

Konfigurieren des Samplings

Die standardmäßige maximale Telemetrierate beträgt fünf Objekte pro Sekunde. Laufzeit 1.x konfiguriert das Sampling unter applicationInsights.sampling:

{
	"applicationInsights": {
		"sampling": {
			"isEnabled": true,
			"maxTelemetryItemsPerSecond": 5
		}
	}
}

Das folgende Beispiel kombiniert Kategorienfilterung und -stichproben:

{
	"logger": {
		"categoryFilter": {
			"defaultLevel": "Warning",
			"categoryLevels": {
				"Function": "Error",
				"Host.Aggregator": "Error",
				"Host.Results": "Information",
				"Host.Executor": "Warning"
			}
		}
	},
	"applicationInsights": {
		"sampling": {
			"isEnabled": true,
			"maxTelemetryItemsPerSecond": 5
		}
	}
}

Runtime 1.x unterstützt keine Konfiguration pro Funktion.

Anwendungs-Insights-Funktionen

Runtime 1.x sammelte automatisch Anfragen, Ausnahmen und Leistungszähler. Es sammelte nicht automatisch HTTP-, Service Bus-, Event Hub- oder SQL-Abhängigkeiten. Es unterstützte QuickPulse/Live Metrics ohne sicheren Steuerkanal und unterstützte Sampling, aber keine Heartbeats, keine Service Bus- oder Event Hubs-Korrelation oder eine vollständig konfigurierbare Telemetriesammlung.

Nicht unterstützte Funktionen und Verhalten in Runtime 1.x

  • Wiederholungsrichtlinien werden nicht unterstützt.
  • Dynamische Überwachung von virtuellen Netzwerk-Triggern wird nicht unterstützt.
  • Bei Premium- und dedizierten Plänen ist die Standardausführungszeit der Funktion unbegrenzt. Im Verbrauchsplan beträgt die Standard-Timeout fünf Minuten und das Maximum 10 Minuten.
  • Eine Funktions-App, die ein Remote-Deployment-Paket verwendet, kann ohne eine Azure Files-Freigabe nicht laufen.

Bindungen, die in Laufzeit 1.x enthalten sind

Azure Functions Runtime 1.x ist ausgeschaltet. Wenn du auf Runtime 4.x migrierst, nutze aktuelle Bindungserweiterungen oder ein Erweiterungsbundle und prüfe jede Bindung auf Konfigurations- und Typänderungen.

Die folgenden Bindungen waren mit Laufzeit 1.x enthalten. Die Spalte C#-Attribut zeigt die im Code verwendeten Kurznamen. Die entsprechenden Klassennamen haben ein Attribute Suffix, wie zum Beispiel BlobTriggerAttribute. C#-Skriptfunktionen definieren stattdessen Bindungen in der function.json-Datei .

Type Trigger Eingabe Output C#-Attribute
Blob Storage Yes Yes Yes [BlobTrigger] (Auslöser)
[Blob] (Eingang/Ausgabe)
Azure Cosmos DB Yes Yes Yes [CosmosDBTrigger] (Auslöser)
[DocumentDB] (Eingang/Ausgabe)
Ereignisraster Yes Nein Nein [EventGridTrigger]
Event Hubs Yes Nein Yes [EventHubTrigger] (Auslöser)
[EventHub] (Ausgabe)
HTTP und Webhooks Yes Nein Yes [HttpTrigger]
IoT Hub Yes Nein Nein [EventHubTrigger]
Mobile Apps Nein Yes Yes [MobileTable]
Benachrichtigungs-Hubs Nein Nein Yes [NotificationHub]
Queuespeicher Yes Nein Yes [QueueTrigger] (Auslöser)
[Queue] (Ausgabe)
SendGrid Nein Nein Yes [SendGrid]
Servicebus Yes Nein Yes [ServiceBusTrigger] (Auslöser)
[ServiceBus] (Ausgabe)
Tabellenspeicher Nein Yes Yes [Table]
Timer Yes Nein Nein [TimerTrigger]
Twilio Nein Nein Yes [TwilioSms]

Funktions-Apps, die Runtime 1.x verwenden, verweisen automatisch auf das Microsoft.Azure. WebJobs NuGet-Paket (Version 2.x).

Die Blob Storage-, Queue Storage- und Table Storage-Trigger und -Bindings verwenden Version 7.2.1 des WindowsAzure.Storage NuGet-Pakets. Wenn du auf eine andere Version des Storage SDK verweis und in deiner Funktionssignatur auf einen Storage SDK-Typ bindest, könnte die Functions-Laufzeit anzeigen, dass sie nicht an diesen Typ gebunden werden kann. Stelle sicher, dass dein Projekt auf WindowsAzure.Storage 7.2.1 verweist.

Blob Storage-Bindungen in Runtime 1.x

Runtime 1.x hat Typen vom veralteten Microsoft offengelegt. WindowsAzure.Storage-Namensraum. Neuere Typen von Azure. Speicher. Blobs benötigen eine spätere Erweiterung und Laufzeit 4.x.

Warteschlangenspeicher-Bindings in Laufzeit 1.x

Runtime 1.x hat Typen vom veralteten Microsoft offengelegt. WindowsAzure.Storage-Namensraum. Neuere Typen von Azure. Speicher. Warteschlangen erfordern eine spätere Erweiterung und Laufzeit 4.x.

Für die Einstellungen für Warteschlangenspeicher-Bindungen siehe den Abschnitt Warteschlangen der Laufzeit 1.x host.json Referenz. In Laufzeit 1.x wird die Einstellung maxPollingInterval in Millisekunden angegeben. In späteren Laufzeitversionen ist TimeSpander Datentyp .

Table Storage Bindings in Laufzeit 1.x

Laufzeit 1.x hat Typen vom veralteten Microsoft freigestellt. WindowsAzure.Storage.Table Namensraum. Neuere Typen von Azure. Data. Tables benötigen die Azure Tables-Erweiterung und Runtime 4.x.

Eingabebeispiele

Die folgende C#-Funktion liest eine einzelne Tabellenzeile. Für jede an die Warteschlange gesendete Nachricht wird die Funktion ausgelöst. Der Zeilenschlüsselwert {queueTrigger} bindet den Zeilenschlüssel an die Nachrichtenmetadaten, d. h. die Nachrichtenzeichenfolge.

public class TableStorage
{
	public class MyPoco
	{
		public string PartitionKey { get; set; }
		public string RowKey { get; set; }
		public string Text { get; set; }
	}

	[FunctionName("TableInput")]
	public static void TableInput(
		[QueueTrigger("table-items")] string input,
		[Table("MyTable", "MyPartition", "{queueTrigger}")] MyPoco poco,
		ILogger log)
	{
		log.LogInformation($"PK={poco.PartitionKey}, RK={poco.RowKey}, Text={poco.Text}");
	}
}

Die folgende C#-Funktion liest mehrere Tabellenzeilen, wobei die MyPoco Klasse von abgeleitet ist TableEntity.

public class TableStorage
{
	public class MyPoco : TableEntity
	{
		public string Text { get; set; }
	}

	[FunctionName("TableInput")]
	public static void TableInput(
		[QueueTrigger("table-items")] string input,
		[Table("MyTable", "MyPartition")] IQueryable<MyPoco> pocos,
		ILogger log)
	{
		foreach (MyPoco poco in pocos)
		{
			log.LogInformation($"PK={poco.PartitionKey}, RK={poco.RowKey}, Text={poco.Text}");
		}
	}
}

Eingangsnutzung

Um eine bestimmte Entität nach Schlüssel zurückzugeben, verwenden Sie einen Bindungsparameter, der von TableEntity abgeleitet wird. Die spezifischen TableName, PartitionKey, und RowKey werden verwendet, um zu versuchen, eine bestimmte Entität aus der Tabelle zu erhalten.

Um Abfragen auszuführen, die mehrere Entitäten zurückgeben, verwenden Sie eine Bindung an ein IQueryable<T>-Objekt mit einem Typ, der von IQueryable<T> erbt.

Ausgabenutzung

Die folgenden Typen werden für out-Parameter und -Rückgabetypen unterstützt:

  • Ein einfaches altbekanntes CLR-Objekt (POCO), das die PartitionKey- und RowKey-Eigenschaften enthält. Sie können diese Eigenschaften begleiten, indem Sie ITableEntity implementieren oder von TableEntity erben.
  • ICollector<T> oder IAsyncCollector<T>, wobei T die PartitionKey- und RowKey-Eigenschaft enthält. Sie können diese Eigenschaften begleiten, indem Sie ITableEntity implementieren oder von TableEntity erben.

Sie können auch als Methodenparameter an CloudTabledas Storage SDK binden. Anschließend können Sie dieses Objekt verwenden, um in die Tabelle zu schreiben.

Event Hubs-Bindungen in Laufzeit 1.x

Runtime 1.x enthielt die Event Hubs-Bindung und benötigte keine separate Erweiterung. Es stellte den veralteten Microsoft.Azure-Typ frei. EventHubs.EventData-Typ. Event Hubs Trigger unterstützten EventData, JSON-serialisierbare Typen, string, sowie byte[] für ein einzelnes Ereignis und EventData[] und string[] für einen Batch. Ausgabebindungen unterstützten EventData, JSON-serialisierbare Typen, string, und byte[].

Für einen Event Hubs-Trigger oder eine Ausgabebindung infunction.jsonverwendet Runtime 1.x die path Eigenschaft für den Namen des Eventhubs. Spätere Laufzeitversionen verwenden eventHubName. Wenn der Name des Eventhubs ebenfalls in der Verbindungszeichenfolge vorhanden ist, überschreibt dieser Wert die Eigenschaft zur Laufzeit.

Die Laufzeit 1.x host.json Datei verwendet ein oberste eventHub Objekt:

{
	"eventHub": {
		"maxBatchSize": 64,
		"prefetchCount": 256,
		"batchCheckpointFrequency": 1
	}
}
Property Vorgabe Description
maxBatchSize 64 Die maximale Ereignisanzahl, die pro Empfangsschleife empfangen wird.
prefetchCount 300 Die standardmäßige Vorabrufanzahl, die vom zugrunde liegenden EventProcessorHost verwendet wird.
batchCheckpointFrequency 1 Die Anzahl der zu verarbeitenden Ereignisbatches, bevor sie einen Ereignishub-Cursorprüfpunkt erstellen.

Für die vollständige Konfigurationsreferenz siehe den eventHub Abschnitt der Laufzeit 1.x host.json Referenz.

Event Grid-Bindungen in Laufzeit 1.x

Event Grid-Erweiterungsversionen älter als 3.x unterstützen das CloudEvents-Schema nicht. Um dieses Schema zu nutzen, verwenden Sie einen HTTP-Trigger oder migrieren Sie auf Runtime 4.x und Event Grid Erweiterung 3.x.

Die Event Grid Ausgabebindung ist nur für Laufzeit 2.x und später verfügbar.

Bindungstypen

Die Laufzeit-1.x-Erweiterung unterstützt folgende Parametertypen. Es unterstützt das CloudEvents-Schema nicht, das die Event Grid-Erweiterung 3.x erfordert.

Verbindlich Parametertypen
Event Grid-Trigger Newtonsoft.Json.Linq.JObject
string

Triggerverwendung

In-process C#-Klassenbibliotheksfunktionen unterstützen folgende Event-Grid-Triggertypen:

  • Newtonsoft.Json.Linq.JObject
  • System.String

Webhook-Endpunkt und Systemschlüssel

Der gehostete Webhook-Endpunkt für einen Runtime 1.x Event Grid-Trigger verwendet folgendes URL-Muster:

https://{functionappname}.azurewebsites.net/admin/extensions/EventGridExtensionConfig?functionName={functionname}&code={systemkey}

Um den Event Grid Systemschlüssel aus der Administrator-API zu erhalten, verwenden Sie den Function App Master Key in der folgenden Anfrage:

https://{functionappname}.azurewebsites.net/admin/host/systemkeys/eventgridextensionconfig_extension?code={masterkey}

Für lokale Tests verwendet der Event Grid Trigger-Endpunkt folgendes URL-Muster:

http://localhost:7071/admin/extensions/EventGridExtensionConfig?functionName={FUNCTION_NAME}

Service Bus-Bindungen in Laufzeit 1.x

Runtime 1.x hat Typen vom veralteten Microsoft freigestellt. ServiceBus.Messaging-Namensraum. Neuere Typen von Azure. Messaging.ServiceBus benötigt Service Bus-Erweiterung 5.x oder höher und Laufzeit 4.x.

Am 30. September 2026 werden die Azure Service Bus SDK-Bibliotheken WindowsAzure.ServiceBus, Microsoft.Azure. ServiceBus und com.microsoft.azure. Servicebus ausmustert. Diese Bibliotheken entsprechen nicht den Richtlinien des Azure SDK. Die Unterstützung für das Service Bus Messaging Protocol (SBMP) wird ebenfalls enden. Obwohl Sie die älteren Bibliotheken auch nach der Pensionierung weiterhin nutzen können, erhalten sie keinen offiziellen Support und keine Updates mehr von Microsoft. Weitere Informationen finden Sie in der Mitteilung zur Beendigung des Supports.

Triggerverwendung

Der Queue- oder Topic-Nachrichtentrigger unterstützt folgende Parametertypen:

In C#-Klassenbibliotheken nimmt der Konstruktor des Attributs den Namen der Warteschlange oder des Themas und des Abonnements an. Du kannst auch die Zugriffsrechte der Verbindung angeben. Wenn Sie keine Zugriffsrechte angeben, ist der Standardwert Manage.

Service Bus-Kontoauswahl

Verwenden Sie das ServiceBusAccountAttribut, um das Service Bus-Konto anzugeben. Der Konstruktor verwendet den Namen einer App-Einstellung, die einen Service Bus Verbindungszeichenfolge enthält. Wenden Sie das Attribut auf Parameter-, Methoden- oder Klassenebene an. Das folgende Beispiel zeigt Attribute auf Klassen- und Methodenebene:

[ServiceBusAccount("ClassLevelServiceBusAppSetting")]
public static class AzureFunctions
{
	[ServiceBusAccount("MethodLevelServiceBusAppSetting")]
	[FunctionName("ServiceBusQueueTriggerCSharp")]
	public static void Run(
		[ServiceBusTrigger("myqueue", AccessRights.Manage)]
		string myQueueItem, ILogger log)
	{
		// ...
	}
}

Die folgende Reihenfolge bestimmt, welches Service Bus-Konto verwendet wird:

  1. Die Eigenschaft ServiceBusTrigger des Attributs Connection.
  2. Das Attribut ServiceBusAccount, das auf den gleichen Parameter angewendet wird wie das Attribut ServiceBusTrigger.
  3. Das Attribut ServiceBusAccount, das auf die Funktion angewendet wird.
  4. Das Attribut ServiceBusAccount, das auf die Klasse angewendet wird.
  5. Die App-Einstellung AzureWebJobsServiceBus.

Metadaten von Nachrichten

Die folgenden Eigenschaften sind Mitglieder der Klassen BrokeredMessage und MessageReceiver .

Property Type Description
ContentType string Ein Inhaltstyp-Identifikator, der vom Sender und Empfänger für anwendungsspezifische Logik verwendet wird.
CorrelationId string Die Korrelations-ID
DeadLetterSource string Die Quelle mit dem Totbuchstaben.
DeliveryCount Int32 Die Anzahl der Übermittlungen.
EnqueuedTimeUtc DateTime Die Warteschlangenzeit in der koordinierten Universalzeit (UTC).
ExpiresAtUtc DateTime Die Ablaufzeit in UTC.
Label string Die anwendungsspezifische Bezeichnung.
MessageId string Ein benutzerdefinierter Wert, der Service Bus verwenden kann, um doppelte Nachrichten zu identifizieren, falls aktiviert.
MessageReceiver MessageReceiver Service Bus Nachrichtenempfänger. Kann verwendet werden, um die Nachricht abzubrechen, zu vervollständigen oder zu vervollständigen.
MessageSession MessageSession Ein Nachrichtenempfänger speziell für sitzungsfähige Warteschlangen und Themen.
ReplyTo string Die Antwort-Warteschlangeadresse.
SequenceNumber long Die eindeutige Nummer, die einer Nachricht von Service Bus zugewiesen ist.
To string Die Send-to-Adresse.
UserProperties IDictionary<string, object> Eigenschaften, die vom Absender festgelegt werden.

Ausgabenutzung

Verwenden Sie den Typ BrokeredMessage, wenn Sie Nachrichten mit Metadaten senden. Definiere Parameter als return Typattribute. Wenn der Parameterwert beim Beenden der Funktion null ist, erzeugt Functions keine Nachricht.

Für function.json bindet, accessRights akzeptiert manage oder listen und setzt standardmäßig auf manage. Wenn die Verbindungszeichenfolge keine Manage-Berechtigung hat, setzen accessRights Sie auf listen , um zu verhindern, dass die Laufzeit Management-Operationen versucht.

Die Laufzeit erstellt die Warteschlange, falls sie nicht existiert, und du setzt accessRights auf manage.

Hosteinstellungen

Für Service Bus Bindungseinstellungen siehe die Referenz Runtime 1.x host.json.

HTTP- und Webhook-Bindungen in Runtime 1.x

Eine HTTP-ausgelöste Funktion wird standardmäßig mit einem leeren Körper zurückgegeben HTTP 200 OK . Spätere Laufzeitversionen kehren zurück.HTTP 204 No Content

Für einen HTTP-Trigger in function.jsonverwenden Sie die webHookType Eigenschaft, um den Trigger so zu konfigurieren, dass er als Webhook-Empfänger für den angegebenen Anbieter fungiert. Diese Eigenschaft ist spezifisch für Laufzeit 1.x.

Runtime 1.x unterstützt keinen Zugriff auf authentifizierte Client-Informationen.

Webhook-Modus

Webhook-Templates bieten zusätzliche Validierung für Webhook-Payloads. Die Bindungseigenschaft webHookType zeigt den Webhook-Anbieter an und steuert die unterstützte Nutzlast:

Typwert Description
genericJson Ein allgemeiner Webhookendpunkt ohne Logik für einen bestimmten Anbieter. Diese Einstellung beschränkt Anfragen auf HTTP POST mit dem Inhaltstyp application/json .
github Die Funktion antwortet auf GitHub-Webhooks. Verwenden Sie die authLevel-Eigenschaft nicht mit GitHub-Webhooks.
slack Die Funktion antwortet auf Slack-Webhooks. Verwenden Sie die authLevel-Eigenschaft nicht mit Slack-Webhooks.

Wenn Sie setzen webHookType, setzen Sie die Eigenschaft methods nicht.

Um auf GitHub-Webhooks zu reagieren, erstellen Sie die Funktion mit einem HTTP-Trigger, setzen webHookType Sie auf github, und kopieren Sie deren URL und API-Schlüssel in die Seite "Webhook hinzufügen" im GitHub-Repository.

Der Slack-Webhook generiert ein Token, also konfiguriere mit diesem Token einen funktionsspezifischen Schlüssel.

Die Webhook-Receiver-Komponente übernimmt die Webhook-Autorisierung. Der Mechanismus variiert je nach Webhook-Typ, aber jeder Mechanismus beruht auf einem Schlüssel. Standardmäßig wird die benannte default Funktionstaste verwendet. Um einen weiteren Schlüssel zu verwenden, konfigurieren Sie den Webhook-Anbieter so, dass er den Schlüsselnamen auf eine der folgenden Arten sendet:

  • Im Abfragestring-Parameter clientid , wie zum https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?clientid=<KEY_NAME>Beispiel .
  • Im x-functions-clientid Anfrage-Header.

Für HTTP-Bindungseinstellungen siehe den Abschnitt HTTP der Runtime 1.x host.json Referenz.

Warmup-Trigger in Laufzeit 1.x

Laufzeit 1.x unterstützt den Warmup-Trigger nicht.

SendGrid-Bindung in Laufzeit 1.x

Fügen Sie ihrem Projekt die Erweiterung hinzu, indem Sie das NuGet-Paket, Version 2.x, installieren.

Für SendGrid-Bindungseinstellungen siehe den Abschnitt SendGrid der Runtime 1.x host.json Referenz.

Twilio-Bindung in Laufzeit 1.x

Fügen Sie die Erweiterung zu Ihrem Projekt hinzu, indem Sie das NuGet-Paket, Version 1.x, installieren.

Für Laufzeit 1.x verwenden Sie die folgenden Bindungskonfigurationseigenschaften in der function.json-Datei :

function.json-Eigenschaft Description
type Auf twilioSms festlegen.
Richtung Auf out festlegen.
Name Variablenname, der im Funktionscode für die Twilio-SMS-Textnachricht verwendet wird
accountSid Stelle den Namen einer App-Einstellung ein, die dein Twilio-Konto Sid (TwilioAccountSid) speichert. Wenn sie nicht festgelegt wird, lautet der Standardname der App-Einstellung AzureWebJobsTwilioAccountSid.
authToken Setze auf den Namen einer App-Einstellung, die dein Twilio-Authentifizierungstoken speichert (TwilioAccountAuthToken). Wenn sie nicht festgelegt wird, lautet der Standardname der App-Einstellung AzureWebJobsTwilioAuthToken.
to Stellen Sie die Telefonnummer ein, an die die SMS gesendet wird.
from Stellen Sie die Telefonnummer ein, von der die SMS gesendet wird.
Inhalt Nutze es, um die SMS-Textnachricht fest zu programmieren, falls du sie nicht dynamisch im Code deiner Funktion einstellen musst.

Verwenden Sie die in diesem Artikel gespeicherten Bindungsinformationen nur, um eine bestehende App zu verstehen. Folgen Sie dem Runtime-Migrationsleitfaden und der aktuellen Bindungsdokumentation, wenn Sie die App aktualisieren.

Häufig gestellte Fragen

Wird Azure Functions Runtime 1.x noch unterstützt?

No. Die Unterstützung für Azure Functions Runtime 1.x endete am 14. September 2026. Migriere betroffene Apps auf Runtime 4.x für volle Unterstützung.

Verwendet ein Python v1 oder Node.js v4 Programmiermodell Runtime 1.x?

No. Sprachprogrammiermodellversionen sind unabhängig von der Laufzeitversion. Die Python v1 und v2 Programmiermodelle sowie die Node.js v3 und v4 laufen auf Laufzeit 4.x.

  • Last updated on