Azure Functions runtime 1.x référence legacy

Important

Le support a pris fin pour la version 1.x de l’exécution Azure Functions le 14 septembre 2026. Migrez vos applications vers la version 4.x pour une prise en charge complète.

Cet article préserve des informations historiques clés et renvoie à des références détaillées pour les applications de fonctions qui utilisent encore l’exécution 1.x. N’utilisez pas runtime 1.x pour les nouvelles applications fonctionnelles.

Portée d’exécution 1.x

Le runtime d'Azure Functions 1.x a atteint la fin du support le 14 septembre 2026, et n'est pas pris en charge pour les applications de fonctions nouvelles ou existantes. Runtime 1.x présentait les caractéristiques suivantes :

Il ne fonctionnait que sous Windows.
Il supportait les applications C# ciblant le framework .NET et les applications JavaScript.
Les applications C# tournaient en cours. Runtime 1.x ne supportait pas le modèle de worker isolé.
Il utilisait la version 1.x d’Azure Functions Core Tools pour le développement local. Core Tools 1.x ne fonctionne que sous Windows.
L’exécution incluait ses liaisons prises en charge. Les versions d’exécution ultérieures utilisent des extensions de liaison ou des bundles d’extensions séparément versionnés.

Versions du modèle d’exécution, d’extension et de programmation

La version d'exécution Azure Functions n'est pas la même que celles utilisées par les extensions de liaison, les bundles d'extensions ou les modèles de programmation langageuse. Une étiquette de version sur un autre composant n'indique pas qu'une application utilise Azure Functions runtime 1.x. Par exemple:

Les modèles de programmation Python v1 et v2 fonctionnent en temps réel 4.x.
Les modèles de programmation Node.js v3 et v4 tournent en mode exécution 4.x.
Les versions du bundle d’extension et du package d’extension binding sont indépendantes de la version d’exécution.

Migrer vers l’exécution 4.x

Pour remettre une application en support complet, la migrer du runtime 1.x vers le runtime 4.x. Le guide de migration couvre les tâches suivantes :

Identifiez les applications qui ciblent le runtime 1.x.
Choisissez une cible prise en charge pour C# ou JavaScript.
Mettez à jour le projet, les liaisons, les paramètres de l’application et host.json fichier.
Testez l’application localement et mettez à jour l’application de fonctions dans Azure.

Ne changez pas seulement les paramètres de l’application FUNCTIONS_EXTENSION_VERSION . Les mises à jour à l’exécution peuvent nécessiter des modifications de projet, de code, de liaison et de configuration.

Paramètres spécifiques à l’exécution 1.x

Le paramètre obsolète AzureWebJobsDashboard n’est pris en charge que par l’exécution 1.x. Il contient un compte de stockage polyvalent optionnel chaîne de connexion utilisé pour stocker les journaux et les afficher dans l’onglet Surveiller du portail Azure.

Clé	Valeur d'échantillon
`AzureWebJobsDashboard`	`DefaultEndpointsProtocol=https;AccountName=...`

Runtime 1.x ne prend pas en charge le AZURE_FUNCTIONS_ENVIRONMENT paramètre de l’application.

La FUNCTIONS_EXTENSION_VERSION valeur ~1 épingle une application fonctionnelle à runtime 1.x. Le stockage des clés dans le système de fichiers (AzureWebJobsSecretStorageType=files) est la valeur par défaut.

La functionsRuntimeAdminIsolationEnabled propriété site n’est pas disponible en runtime 1.x. Ce FUNCTIONS_V2_COMPATIBILITY_MODE paramètre ne s’applique pas aux applications en temps d’exécution 1.x.

Project et différences linguistiques

Les projets de bibliothèque de classes C# 1.x à l’exécution ciblaient le framework .NET et utilisaient la version 1.x du Microsoft.NET.Sdk.Functions paquet. Ils pourraient être utilisés TraceWriter pour l’exploitation forestière. Pour le modèle de projet C# actuel et les considérations de migration, consultez le guide du développeur de la bibliothèque de classes .NET et le guide de migration runtime 1.x.

Projets de bibliothèque de classes C#

L’exemple suivant montre les parties pertinentes d’un fichier projet 1.x à l’exécution :

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

Les Microsoft.NET.Sdk.Functions dépendances des paquets incluent des déclencheurs et des liaisons. Un projet 1.x fait référence aux déclencheurs et liaisons 1.x car ils ciblent le cadre .NET. Le colis dépend également de Newtonsoft.Json et indirectement sur WindowsAzure.Storage. Ces dépendances garantissent que le projet utilise des versions compatibles avec l’exécution des Fonctions ciblées. Par exemple, l’exécution Functions qui cible .NET Framework 4.6.1 est compatible avec la 9.0.1, et non avec Newtonsoft.Json la version 11.

Runtime 1.x utilisé TraceWriter pour la journalisation d’Application Insights. TraceWriter ne supporte pas la journalisation structurée.

L’exemple suivant crée un TelemetryClient et utilise TrackEvent, TrackMetric, et TrackDependency pour enregistrer une télémétrie personnalisée. Il utilise également le contexte d’exécution de la fonction pour corréler la télémétrie personnalisée avec l’invocation courante.

Exemple de télémétrie personnalisée

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 supportait également le script C# (.csx) et les fonctions JavaScript. Le script C# n’est pas spécifique à l’exécution 1.x, donc utilisez la référence développeur de script C# pour des conseils généraux sur les scripts. Utilisez le guide de migration pour les modifications spécifiques à l’exécution.

Pour des exemples de la syntaxe C# antérieure, voir les modèles de fonctions runtime 1.x.

Assemblages et packages de scripts C#

Dans les fonctions de script C# 1.x à l’exécution, vous pouvez référencer les assemblages suivants par un simple nom :

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

Runtime 1.x utilisait un fichier project.json pour définir des dépendances. L’exemple suivant ajoute le Microsoft.ProjectOxford.Face package NuGet :

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

Les extensions bundles ne sont pas pris en charge par la version 1.x en temps réel. Pour utiliser un flux NuGet personnalisé, spécifiez le flux dans un fichier NuGet.Config dans le dossier racine de l’application fonction. Pour plus d’informations, consultez la page Configurer le comportement de NuGet.

Développement local avec Core Tools 1.x

La version 1.x d’Azure Functions Core Tools est associée à l’exécution 1.x et ne fonctionne que sur Windows. Pour commencer la durée de jeu, vous avez exécuté func host start. Pour les recommandations actuelles sur le développement local, voir Develop Azure Functions locally using Core Tools.

Visual Studio stockait les versions runtime 1.x des Core Tools et %USERPROFILE%\AppData\Local\Azure.Functions.Cli utilisait la dernière version stockée là-bas. Vous pouviez voir la version sélectionnée dans la sortie console lors de l’exécution du projet :

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

Référence de host.json runtime 1.x

Le schéma host.json et les réglages ont changé après l’exécution 1.x. Consultez la référence d’exécution 1.x host.json lors de la revue d’une configuration existante, et comparez-la avec la référence host.json actuelle lors de la migration.

Surveillez les applications 1.x en temps d’exécution avec Application Insights

Runtime 1.x utilise les catégories de journaux suivantes d’Application Insights :

Catégorie	Table	Description
`Function`	traces	Les journaux générés par l’utilisateur, qui peuvent être de n’importe quel niveau de journalisation.
`Host.Aggregator`	customMetrics	Comptage et moyennes des invocations de fonctions sur une période configurable. Le résultat par défaut est de 30 secondes ou 1 000 résultats, selon la première éventualité. Ces journaux sont écrits au niveau `Information`.
`Host.Executor`	traces	Fonction lancée et terminée des journaux. Les exécutions réussies utilisent `Information`, les exceptions utilisent `Error`, et des conditions telles que les messages poison-queue utilisent `Warning`.
`Host.Results`	requêtes	Succès ou échec des exécutions de fonctions. Ces journaux sont écrits au niveau `Information`.

Configurer des niveaux de journaux

Runtime 1.x configure les niveaux de logarithèmes sous logger.categoryFilter danshost.json:

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

Lorsque plusieurs noms de catégories commencent par la même chaîne, la catégorie la plus spécifique est associée en premier. L’exemple suivant enregistre tout sauf Host.Aggregator au Error niveau :

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

Configurer l’échantillonnage

Le taux de télémétrie maximal par défaut est de cinq objets par seconde. Runtime 1.x configure l’échantillonnage sous applicationInsights.sampling:

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

L’exemple suivant combine filtrage par catégories et échantillonnage :

{
	"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 ne prend pas en charge la configuration par fonction.

Capacités d’Application Insights

Runtime 1.x collectait automatiquement les requêtes, exceptions et compteurs de performance. Il ne collectait pas automatiquement les dépendances HTTP, Service Bus, Event Hubs ou SQL. Il supportait QuickPulse/Live Metrics sans canal de contrôle sécurisé et prenait en charge l'échantillonnage, mais il ne supportait pas les battements de cœur, la corrélation Service Bus ou Event Hubs, ni la collecte de télémétrie entièrement configurable.

Fonctionnalités et comportements non pris en charge dans l’exécution 1.x

Les politiques de réessaisance ne sont pas prises en charge.
La surveillance dynamique à grande échelle des déclencheurs réseau virtuels n’est pas prise en charge.
Sur les forfaits Premium et dédiés, le délai d’exécution par défaut de la fonction est illimité. Sur le forfait Consommation, le délai par défaut est de cinq minutes et le maximum de 10 minutes.
Une application de fonctions qui utilise un package de déploiement à distance ne peut pas s'exécuter sans un partage Azure Files.

Assignations incluses dans le runtime 1.x

Azure Functions runtime 1.x est retiré. Lorsque vous migrez vers l’exécution 4.x, utilisez des extensions de liaison courante ou un bundle d’extensions et examinez chaque liaison pour les changements de configuration et de type.

Les liaisons suivantes étaient incluses dans le runtime 1.x. La colonne d’attributs C# montre les noms courts utilisés dans le code. Les noms de classes correspondants ont un Attribute suffixe, comme BlobTriggerAttribute. Les fonctions de script C# définissent plutôt des liaisons dans le fichierfunction.json .

Type	Gâchette	Input	Sortie	Attributs C#
Stockage Blob	Yes	Yes	Yes	`[BlobTrigger]` (gâchette) `[Blob]` (entrée/sortie)
Azure Cosmos DB	Yes	Yes	Yes	`[CosmosDBTrigger]` (gâchette) `[DocumentDB]` (entrée/sortie)
Grille d’événements	Yes	No	No	`[EventGridTrigger]`
Hubs d’événements	Yes	No	Yes	`[EventHubTrigger]` (gâchette) `[EventHub]` (sortie)
HTTP et webhooks	Yes	No	Yes	`[HttpTrigger]`
IoT Hub	Yes	No	No	`[EventHubTrigger]`
Applications mobiles	No	Yes	Yes	`[MobileTable]`
Centres de notification	No	No	Yes	`[NotificationHub]`
Stockage de files d’attente	Yes	No	Yes	`[QueueTrigger]` (gâchette) `[Queue]` (sortie)
SendGrid	No	No	Yes	`[SendGrid]`
Service Bus	Yes	No	Yes	`[ServiceBusTrigger]` (gâchette) `[ServiceBus]` (sortie)
Stockage de table	No	Yes	Yes	`[Table]`
Minuteur	Yes	No	No	`[TimerTrigger]`
Twilio	No	No	Yes	`[TwilioSms]`

Les applications de fonction qui utilisent l’exécution 1.x référencent automatiquement le paquet Microsoft.Azure. WebJobs NuGet (version 2.x).

Les déclencheurs et liaisons Stockage Blob, Queue Storage et Table Storage utilisent la version 7.2.1 du paquet NuGet WindowsAzure.Storage. Si vous référencez une version différente du SDK de stockage et que vous liez à un type de SDK de stockage dans votre signature de fonction, l’exécution des fonctions pourrait indiquer qu’il ne peut pas se lier à ce type. Assurez-vous que votre projet fait référence à WindowsAzure.Storage 7.2.1.

Stockage Blob bindings en runtime 1.x

Runtime 1.x exposait les types issus de l’espace de noms Microsoft. WindowsAzure.Storage. Des types plus récents depuis Azure. Storage.Blobs nécessitent une extension ultérieure et un temps d’exécution 4.x.

Assignations de stockage en file d’attente dans l’exécution 1.x

Runtime 1.x exposait les types issus de l’espace de noms Microsoft. WindowsAzure.Storage. Des types plus récents depuis Azure. Storage.Queues nécessitent une extension ultérieure et un temps d’exécution 4.x.

Pour les paramètres de liaison de stockage en file d’attente, voir la section files d’attente de la référence d’exécution 1.x host.json. En temps d’exécution 1.x, le maxPollingInterval paramètre est exprimé en millisecondes. Dans les versions ultérieures à l’exécution, son type de données est TimeSpan.

Liaisons de stockage de table en temps d’exécution 1.x

Runtime 1.x exposait les types issus de l’espace de noms Microsoft. WindowsAzure.Storage.Table. Des types plus récents provenant d’Azure. Data.Tables nécessitent l’extension Azure Tables et l’exécution 4.x.

Exemples d’entrée

La fonction C# suivante lit une seule ligne de tableau. Pour chaque message envoyé à la file d’attente, la fonction est déclenchée. La valeur de clé de ligne {queueTrigger} lie la clé de ligne aux métadonnées de message, laquelle correspond à la chaîne de message.

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

La fonction C# suivante lit plusieurs lignes de table dont la MyPoco classe dérive de 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}");
		}
	}
}

Utilisation des entrées

Pour retourner une entité spécifique par clé, utilisez un paramètre de liaison qui dérive de TableEntity. Les spécifiques TableName, PartitionKey, , et RowKey sont utilisées pour essayer d’obtenir une entité spécifique à partir de la table.

Pour exécuter des requêtes qui retournent plusieurs entités, effectuez une liaison à un IQueryable<T> d’un type qui hérite de IQueryable<T>.

Utilisation de la sortie

Les types suivants sont pris en charge pour les paramètres out et les types de retour :

Un objet POCO (plain-old CLR object) qui comprend les propriétés PartitionKey et RowKey. Vous pouvez accompagner ces propriétés en implémentant ITableEntity ou en héritant TableEntity.
ICollector<T> ou IAsyncCollector<T> où T inclut les propriétés PartitionKey et RowKey. Vous pouvez accompagner ces propriétés en implémentant ITableEntity ou en héritant TableEntity.

Vous pouvez également effectuer une liaison à CloudTablepartir du Kit de développement logiciel (SDK ) de stockage en tant que paramètre de méthode. Vous pouvez ensuite utiliser cet objet pour écrire dans la table.

Assignations Event Hubs en runtime 1.x

Runtime 1.x incluait la liaison des Event Hubs et ne nécessitait pas d’extension séparée. Il a exposé le type Microsoft.Azure. EventHubs.EventData, qui était obsolète. Les déclencheurs des hubs d’événements supportent EventData, types sérialisables JSON, string, et byte[] pour un seul événement, et EventData[] et string[] pour un lot de groupes. Liens de sortie pris en charge EventData, types sérialisables JSON, string, et byte[].

Pour un déclencheur ou une liaison de sortie dans les hubs d’événements dansfunction.json, runtime 1.x utilise la path propriété pour le nom du hub d’événements. Les versions d’exécution ultérieures utilisent eventHubName. Lorsque le nom du hub d’événements est également présent dans la chaîne de connexion, cette valeur supprime la propriété à l’exécution.

Le fichier host.json 1.x à l’exécution utilise un objet de premier niveau eventHub :

{
	"eventHub": {
		"maxBatchSize": 64,
		"prefetchCount": 256,
		"batchCheckpointFrequency": 1
	}
}

Propriété	Default	Description
`maxBatchSize`	64	Nombre d’événements maximal reçu par boucle de réception.
`prefetchCount`	300	Nombre de pré-récupérations par défaut utilisé par le `EventProcessorHost` sous-jacent.
`batchCheckpointFrequency`	1	Nombre de lots d’événements à traiter avant de créer un point de contrôle de curseur Event Hubs.

Pour la référence complète de configuration, voir la eventHub section de la référence 1.x host.json runtime.

Liens de grille d’événements dans l’exécution 1.x

Les versions d’extension Event Grid antérieures à la 3.x ne prennent pas en charge le schéma CloudEvents. Pour consommer ce schéma, utilisez un déclencheur HTTP ou migrez vers l’exécution 4.x et l’extension Event Grid 3.x.

La liaison de sortie Event Grid n’est disponible que pour l’exécution 2.x et ultérieures.

Types de liaisons

L’extension runtime 1.x prend en compte les types de paramètres suivants. Il ne prend pas en charge le schéma CloudEvents, qui nécessite l’extension Event Grid 3.x.

Liaison	Types de paramètres
Déclencheur Event Grid	`Newtonsoft.Json.Linq.JObject` `string`

Utilisation des déclencheurs

Les fonctions de la bibliothèque de classes C# en cours prennent en charge les types de déclencheurs suivants de la grille d’événements :

Newtonsoft.Json.Linq.JObject
System.String

Terminaison Webhook et clé système

Le point de terminaison webhook hébergé pour un déclencheur d’Event Grid 1.x à l’exécution utilise le schéma d’URL suivant :

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

Pour obtenir la clé système Event Grid depuis l’API administrateur, utilisez la clé maîtresse de l’application fonction dans la requête suivante :

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

Pour les tests locaux, le point de déclenchement de la grille d’événements utilise le motif URL suivant :

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

Assignations Service Bus en runtime 1.x

Runtime 1.x exposait les types issus de l’espace de noms Microsoft, déprécié. ServiceBus.Messagerising. Des types plus récents depuis Azure. Messaging.ServiceBus nécessite l’extension Service Bus 5.x ou ultérieure et l’exécution 4.x.

Le 30 septembre 2026, les bibliothèques SDK Azure Service Bus WindowsAzure.ServiceBus, Microsoft.Azure. ServiceBus, et com.microsoft.azure. ServiceBus seront retirées. Ces bibliothèques ne respectent pas les directives des Kit de développement logiciel (SDK) Azure. Le support du protocole de messagerie Service Bus (SBMP) prendra également fin. Bien que vous puissiez continuer à utiliser les anciennes bibliothèques après la retraite, elles ne recevront plus de support officiel ni de mises à jour de la part de Microsoft. Pour plus d’informations, consultez l’annonce concernant l’arrêt de la prise en charge.

Utilisation des déclencheurs

Le déclencheur de message de file d’attente ou de sujet prend en charge les types de paramètres suivants :

BrokeredMessage vous donne le message désérialisé avec la méthode BrokeredMessage.GetBody<T>( ).
MessageReceiver reçoit et accuse réception des messages provenant du conteneur de messages. Ce type est requis lorsque autoComplete est défini à false.

Dans les bibliothèques de classes C#, le constructeur de l’attribut prend le nom de la file d’attente ou du sujet et de l’abonnement. Vous pouvez également spécifier les droits d’accès de la connexion. Si vous ne spécifiez pas de droits d’accès, la valeur par défaut est Manage.

Sélection de compte Service Bus

Utilisez ServiceBusAccountAttribute pour spécifier le compte Service Bus. Le constructeur prend le nom d’un paramètre d’application qui contient un Service Bus chaîne de connexion. Appliquez l’attribut au niveau du paramètre, de la méthode ou de la classe. L’exemple suivant montre les attributs au niveau de la classe et au niveau de la méthode :

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

L’ordre suivant détermine quel compte Service Bus utiliser :

La propriété ServiceBusTrigger de l’attribut Connection.
L’attribut ServiceBusAccount appliqué au même paramètre que l’attribut ServiceBusTrigger.
L’attribut ServiceBusAccount appliqué à la fonction.
L’attribut ServiceBusAccount appliqué à la classe.
Le paramètre d’application AzureWebJobsServiceBus.

Métadonnées de message

Les propriétés suivantes sont membres des classes BrokeredMessage et MessageReceiver .

Propriété	Type	Description
`ContentType`	`string`	Un identifiant de type de contenu utilisé par l’expéditeur et le destinataire pour la logique spécifique à l’application.
`CorrelationId`	`string`	ID de corrélation.
`DeadLetterSource`	`string`	La source sans vie.
`DeliveryCount`	`Int32`	Le nombre de remises.
`EnqueuedTimeUtc`	`DateTime`	L’heure en file d’attente en temps universel coordonné (UTC).
`ExpiresAtUtc`	`DateTime`	Le délai d'expiration en UTC.
`Label`	`string`	L’étiquette spécifique de l’application.
`MessageId`	`string`	Valeur définie par l’utilisateur que Service Bus pouvez utiliser pour identifier les messages dupliqués, le cas échéant.
`MessageReceiver`	`MessageReceiver`	Service Bus récepteur de messages. Peut être utilisé pour abandonner, compléter ou faire passer le message par lettre morte.
`MessageSession`	`MessageSession`	Récepteur de messages spécifiquement pour les files d’attente et les rubriques activées par la session.
`ReplyTo`	`string`	L’adresse de la file d’attente de réponse.
`SequenceNumber`	`long`	Numéro unique affecté à un message par Service Bus.
`To`	`string`	L’adresse d’envoi.
`UserProperties`	`IDictionary<string, object>`	Propriétés définies par l’expéditeur.

Utilisation de la sortie

Utilisez le type BrokeredMessage pour envoyer des messages contenant des métadonnées. Définissez les paramètres comme return des attributs de type. Si la valeur du paramètre est nulle lorsque la fonction se termine, Fonctions ne crée pas de message.

Pour function.json liaisons, accessRights accepte manage ou listen et par défaut à manage. Si la chaîne de connexion n'a pas la permission de gestion, réglez accessRights pour listen empêcher l'exécution de tenter des opérations de gestion.

L’exécution crée la file d’attente si elle n’existe pas et que vous réglez accessRights sur manage.

Paramètres d’hôte

Pour Service Bus paramètres de liaison, voir la référence runtime 1.x host.json.

Liens HTTP et webhook dans l’exécution 1.x

Une fonction déclenchée par HTTP revient HTTP 200 OK par défaut avec un corps vide. Les versions d’exécution ultérieures reviennent HTTP 204 No Content.

Pour un déclencheur HTTP dans function.json, utilisez la webHookType propriété pour configurer le déclencheur afin qu’il agisse comme un récepteur webhook pour le fournisseur spécifié. Cette propriété est spécifique à l’exécution 1.x.

Runtime 1.x ne supporte pas l’accès aux informations clients authentifiées.

Mode webhook

Les modèles de webhook fournissent une validation supplémentaire pour les charges utiles webhook. La propriété de webHookType liaison montre le fournisseur du webhook et contrôle la charge utile prise en charge :

Valeur du type	Description
`genericJson`	Point de terminaison webhook à usage général sans logique pour un fournisseur spécifique. Ce paramètre limite les requêtes à HTTP POST avec le type de `application/json` contenu.
`github`	La fonction répond aux webhooks GitHub. N’utilisez pas la propriété `authLevel` avec les webhook GitHub.
`slack`	La fonction répond aux webhooks Slack. N’utilisez pas la propriété `authLevel` avec des webhooks Slack.

Quand vous définissez webHookType, ne définissez pas la methods propriété.

Pour répondre aux webhooks GitHub, créez la fonction avec un déclencheur HTTP, réglez webHookType sur github, et copiez son URL et sa clé API dans la page Ajouter webhook du dépôt GitHub.

Le webhook Slack génère un jeton, donc configurez une clé spécifique à une fonction avec ce jeton.

Le composant récepteur webhook gère l’autorisation webhook. Le mécanisme varie selon le type de webhook, mais chaque mécanisme repose sur une clé. Par défaut, la touche de fonction nommée default est utilisée. Pour utiliser une autre clé, configurez le fournisseur de webhook pour qu’il envoie le nom de la clé de l’une des manières suivantes :

Dans le clientid paramètre de la chaîne de requête, tel que https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?clientid=<KEY_NAME>.
Dans l’en-tête x-functions-clientid de la requête.

Pour les paramètres de liaison HTTP, voir la section HTTP de la référence d’exécution 1.x host.json.

Déclencheur d’échauffement en runtime 1.x

Runtime 1.x ne prend pas en charge le déclencheur de réchauffement.

Liaison SendGrid en temps d’exécution 1.x

Ajoutez l’extension à votre projet en installant le package NuGet, version 2.x.

Pour les paramètres de liaison SendGrid, voir la section SendGrid de la référence 1.x host.json runtime.

Liaison Twilio en runtime 1.x

Ajoutez l’extension à votre projet en installant le package NuGet version 1.x.

Pour l’exécution 1.x, utilisez les propriétés de configuration de liaison suivantes dans le fichier function.json :

Propriété function.json	Description
type	Réglez sur `twilioSms`.
direction	Réglez sur `out`.
name	Nom de la variable utilisée dans le code de fonction pour le SMS Twilio.
accountSid	Réglez sur le nom d’un paramètre d’application qui contient le Sid de votre compte Twilio (`TwilioAccountSid`). S’il n’est pas défini, le nom par défaut de l’application est `AzureWebJobsTwilioAccountSid`.
authToken	Réglez sur le nom d’un paramètre d’application qui contient votre jeton d’authentification Twilio (`TwilioAccountAuthToken`). S’il n’est pas défini, le nom par défaut de l’application est `AzureWebJobsTwilioAuthToken`.
to	Réglez sur le numéro de téléphone auquel le SMS est envoyé.
from	Réglez sur le numéro de téléphone d’où le SMS est envoyé.
body	Utilisez le code en dur du SMS si vous n’avez pas besoin de le définir dynamiquement dans le code de votre fonction.

Utilisez les informations de liaison conservées dans cet article uniquement pour comprendre une application existante. Suivez le guide de migration à l’exécution et la documentation actuelle de liaison lorsque vous mettez à jour l’application.

Questions fréquemment posées

Le runtime d’Azure Functions 1.x est-il toujours pris en charge ?

Non. Le support d’exécution d’Azure Functions 1.x a pris fin le 14 septembre 2026. Migrez les applications affectées vers le runtime 4.x pour un support complet.

Un modèle de programmation Python v1 ou Node.js v4 utilise-t-il l’exécution 1.x ?

Non. Les versions des modèles de programmation langage sont indépendantes de la version à l’exécution. Les modèles de programmation Python v1 et v2 ainsi que les modèles de programmation Node.js v3 et v4 fonctionnent sur la version 4.x à l’exécution.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-09-18

Azure Functions runtime 1.x référence legacy

Portée d’exécution 1.x

Versions du modèle d’exécution, d’extension et de programmation

Migrer vers l’exécution 4.x

Paramètres spécifiques à l’exécution 1.x

Project et différences linguistiques

Projets de bibliothèque de classes C#

Exemple de télémétrie personnalisée

Assemblages et packages de scripts C#

Développement local avec Core Tools 1.x

Référence de host.json runtime 1.x

Surveillez les applications 1.x en temps d’exécution avec Application Insights

Configurer des niveaux de journaux

Configurer l’échantillonnage

Capacités d’Application Insights

Fonctionnalités et comportements non pris en charge dans l’exécution 1.x

Assignations incluses dans le runtime 1.x

Stockage Blob bindings en runtime 1.x

Assignations de stockage en file d’attente dans l’exécution 1.x

Liaisons de stockage de table en temps d’exécution 1.x

Exemples d’entrée

Utilisation des entrées

Utilisation de la sortie

Assignations Event Hubs en runtime 1.x

Liens de grille d’événements dans l’exécution 1.x

Types de liaisons

Utilisation des déclencheurs

Terminaison Webhook et clé système

Assignations Service Bus en runtime 1.x

Utilisation des déclencheurs

Sélection de compte Service Bus

Métadonnées de message

Utilisation de la sortie

Paramètres d’hôte

Liens HTTP et webhook dans l’exécution 1.x

Mode webhook

Déclencheur d’échauffement en runtime 1.x

Liaison SendGrid en temps d’exécution 1.x

Liaison Twilio en runtime 1.x

Questions fréquemment posées

Le runtime d’Azure Functions 1.x est-il toujours pris en charge ?

Un modèle de programmation Python v1 ou Node.js v4 utilise-t-il l’exécution 1.x ?

Ressources associées

Commentaires

Ressources supplémentaires